Kristján Valur Jónsson wrote: > 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 think RFC793 is actually pretty clear in stating that: """ If the receiver [of the RST packet] was in any other state, it aborts the connection and advises the user and goes to the CLOSED state. """ But alas, Microsoft thinks they know better.. A brief search yields a number of threads on mailing lists for proxies having to deal with this "feature". The solution that I see as most viable is temporarily making the sockets nonblocking before the connect() and scheduling our own timeout. The only variation on this is I have seen is to use GetTcpTable() to retrieve the status of the socket to determine the state of the socket (since a timeout would kill connects() that are just slow too..). -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu _______________________________________________ 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
