Kristján Valur Jónsson wrote:
Aha, thanks, since my wireshark wasn't working.
I boiled a few pints of water (thanks, Google) and came up with this:
http://support.microsoft.com/kb/175523
Here is the summary:
Note that with other implementations of TCP, such as those commonly found in
many UNIX systems, the connect() fails immediately upon the receipt of the
first ACK/RST packet, resulting in the awareness of an error very quickly.
However, this behavior is not specified in the RFCs and is left to each
implementation to decide. The approach of Microsoft platforms is that the
system administrator has the freedom to adjust TCP performance-related settings
to their own tastes, namely the maximum retry that defaults to 3. The advantage
of this is that the service you're trying to reach may have temporarily shut
down and might resurface in between SYN attempts. In this case, it's convenient
that the connect() waited long enough to obtain a connection since the service
really was there.
Yet another "undefined" thing affecting us, Martin.
I know it's pointless to express my shock here, but I can't resist. It's
truly amazing to me that they'd delay the connect call's failure for a
second by default, in hopes that the other end might come back up
between SYN's. How often could that possibly happen?
Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
