Further testing today seems to indicate that it is an issue specific to a
Win2k, and it is not limited to curl, or a single machine. The latency
issues where a red herring as well, it just so happens that those conditions
probably exacerbated the problem.

For those interested, I took curl out of the picture and wrote a simple
(using blocking calls) winsock app to test with. What I found was that I
got "special" behavior when connecting to ports 80, 81, and 8080.

What I mean by "special" is as follows. I attempted to connect to a machine
that was running but that I knew had no services listening on my target
ports. For most of the ports I tried, the call to connect() would fail, and
if I attemted to send() or recv() on that socket, these calls would fail as
expected with a socket not connected error (winsock 10057).

When I attempted to connect to one of the 3 "special" ports, my connect()
would not fail, the send() would work and recv() would always just return 0
as if the connection were closed.

Looking at a tcpdump trace, I saw the same exact of traffic on the wire
regardless of the port I was connecting to, that is a SYN request sent to
the server which sends an RST as a response.

I repeated this test tens of times with 100% reproducability. I then went
over to another Win2k machine and repeated the test with the same results.
As a final test, I dual booted this machine into Suse Linux, recompiled my
test app, and ran my tests and all connection attempts failed as expected.
I believe that this absolved the machine and network from any blame.

So, it would appear to me that there is something in the bowels of the Win2k
TCP/IP that is doing something "funny" with "HTTP-ish" port numbers, but I
still find it hard to believe.

_________________________________________________________________
Stay informed on Election 2004 and the race to Super Tuesday.
http://special.msn.com/msn/election2004.armx
Received on 2004-03-01