krb5_sendauth vs NAGLE vs DelayedAck
John Hascall
john at iastate.edu
Wed Jan 14 15:22:34 EST 2009
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
More information about the Kerberos
mailing list