Don't include des.h (or variants thereof); krb.h will do it.

(sendline): Add the \r\n to the line in a temporary buffer, and write it all at
once.

1 files changed, 18 insertions, 17 deletions

diff --git a/lib-src/pop.c b/lib-src/pop.c
index 9a85ba3746c..30a4233d417 100644
--- a/lib-src/pop.c
+++ b/lib-src/pop.c
@@ -76,17 +76,6 @@ extern struct servent *hes_getservbyname (/* char *, char * */);
 # ifdef HAVE_KRB5_H
 #  include <krb5.h>
 # endif
-# ifdef HAVE_DES_H
-#  include <des.h>
-# else
-#  ifdef HAVE_KERBEROSIV_DES_H
-#   include <kerberosIV/des.h>
-#  else
-#   ifdef HAVE_KERBEROS_DES_H
-#    include <kerberos/des.h>
-#   endif
-#  endif
-# endif
 # ifdef HAVE_KRB_H
 #  include <krb.h>
 # else
@@ -1403,12 +1392,24 @@ sendline (server, line)
 {
 #define SENDLINE_ERROR "Error writing to POP server: "
   int ret;
-
-  ret = fullwrite (server->file, line, strlen (line));
-  if (ret >= 0)
-    {				/* 0 indicates that a blank line was written */
-      ret = fullwrite (server->file, "\r\n", 2);
-    }
+  char *buf;
+
+  /* Combine the string and the CR-LF into one buffer.  Otherwise, two
+     reasonable network stack optimizations, Nagle's algorithm and
+     delayed acks, combine to delay us a fraction of a second on every
+     message we send.  (Movemail writes line without \r\n, client
+     kernel sends packet, server kernel delays the ack to see if it
+     can combine it with data, movemail writes \r\n, client kernel
+     waits because it has unacked data already in its outgoing queue,
+     client kernel eventually times out and sends.)
+
+     This can be something like 0.2s per command, which can add up
+     over a few dozen messages, and is a big chunk of the time we
+     spend fetching mail from a server close by.  */
+  buf = alloca (strlen (line) + 3);
+  strcpy (buf, line);
+  strcat (buf, "\r\n");
+  ret = fullwrite (server->file, buf, strlen (buf));
 
   if (ret < 0)
     {