I’ve noticed that Windows TCP stack (AppVeyor) seems to take a long time
(>200 msec!) to establish connections. I’ve a strong theory that this is a
bad interaction between Nagle’s algorithm and TCP delayed ack behavior,
although I’ve not proven it yet.
As a consequence of this though, its likely that you might not be able to
send or receive traffic across Windows TCP connections until a fairly large
time has passed. I’ve taken to delaying 1second in the test suite, which
is clearly not ideal.
My guess is that the number is somewhere between 200 & 400 msec; testing
this on AppVeyor is painful, so I’ve not really put any effort into it. In
my own mind Windows is a second class citizen, if only because I am not a
Windows expert, and nobody else who is both a Windows developer and has
solid understanding of libnanomsg’s state machines has stepped forward.
(Implied here is a request that if such a person does exist, he or she
step forward.)
I will probably spend some effort into disabling Nagle by default, and also
honoring the TCP_NODELAY socket options.
The reversal of the default may affect some people, but I expect that as
most folks prefer lower latencies for their messaging instead of
throughput, that the default to not use Nagle will be preferable for
~everyone.
This should (I hope!) make Windows TCP connection establishment go much
faster too.
If there are serious concerns about this, please let me know ASAP.
- Garrett
