[Python-Dev] socket.create_connection slow (original) (raw)

Scott Dial scott+python-dev at scottdial.com
Thu Jan 15 00:19:53 CET 2009

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 scott at scottdial.com scodial at cs.indiana.edu

More information about the Python-Dev mailing list