krb5_sendauth vs NAGLE vs DelayedAck

[John Hascall]

I don't recall having seen this discussed on this
list and google doesn't seem to either, so...

I just discovered that hard way that the way that
krb5_sendauth/krb5_recvauth work tickles the nasty
interaction between the TCP NAGLE and DelayedAck
features which inserts two ~200ms delays into the
process:

 16994 accessd 1231948663.402557 CALL  read(6,0xbfbffa54,4)
 16994 accessd 1231948663.402561 GIO   fd 6 read 4 bytes
       "\0\0\0\^S"
 16994 accessd 1231948663.402567 CALL  read(6,0xa1e0520,0x13)
 16994 accessd 1231948663.592835 GIO   fd 6 read 19 bytes
       "KRB5_SENDAUTH_V1.0\0"
 16994 accessd 1231948663.592850 CALL  read(6,0xbfbff914,4)
 16994 accessd 1231948663.592854 GIO   fd 6 read 4 bytes
       "\0\0\0\b"
 16994 accessd 1231948663.592860 CALL  read(6,0xa1e2530,8)
 16994 accessd 1231948663.592863 GIO   fd 6 read 8 bytes
       "PV 1.00\0"
 16994 accessd 1231948663.592868 CALL  write(6,0xbfbff99b,1)
 16994 accessd 1231948663.592874 GIO   fd 6 wrote 1 bytes
       "\0"
 16994 accessd 1231948663.592879 CALL  read(6,0xbfbff914,4)
 16994 accessd 1231948663.593675 GIO   fd 6 read 4 bytes
       "\0\0\^A\M^U"
 16994 accessd 1231948663.593681 CALL  read(6,0xa165800,0x195)
 16994 accessd 1231948663.792905 GIO   fd 6 read 405 bytes
       "...a bunch of binary goop..."

This was pretty annoying when that 4/10s of a second was
pretty much all of the connection lifetime.

My guess is that this occurs anywhere that the kerberos
libs use krb5_write_message().

My solution was just to do:
  int on = 1;
  setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &on, sizeof(on));
before calling krb5_sendauth() but a "better" approach might
be for krb5_write_message to end up calling writev so it
does one write instead of two, I think.


John