[Python-Dev] socket.create_connection slow

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