[Python-Dev] socket.create_connection slow
Kristján Valur Jónsson
kristjan at ccpgames.com
Wed Jan 14 22:40:19 CET 2009
Aha, thanks, since my wireshark wasn't working.
I boiled a few pints of water (thanks, Google) and came up with this:
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.
From: "Martin v. Löwis" [mailto:martin at v.loewis.de]
Sent: 14. janúar 2009 20:31
To: Kristján Valur Jónsson
Cc: Victor Stinner; python-dev at python.org
Subject: Re: [Python-Dev] socket.create_connection slow
> I have no idea why the connect refusal takes so long.
> Maybe it's a vista thing?
I've looked into this further. It doesn't just happen for
localhost, but also for remote hosts, and not just for IPv6,
but also for IPv4, and not just for Vista, but also for XP.
The problem is this:
1. Vista sends SYN to target machine (say, through v6)
2. Target machine has no port open, and responds with
3. Vista waits 0.5s
4. Vista sends another SYN to target machine
5. Target machine responds with another RST,ACK
6. Vista waits another 0.5s
7. Vista retries a third time, again getting no connection
8. Vista gives up, having spend 1s in trying to establish
a connection to a remote port where the remote system
has confirmed that the connection is refused already
a second ago.
I have not found documentation for this feature of the
Windows TCP stack, yet. There is the TcpMaxConnectRetransmissions
parameter, but this supposed affects requests without responses
(and supposed also starts of with 3s)
More information about the Python-Dev