Client-side TCP socket receiving "Address already in use" upon connect
Steve Holden
steve at holdenweb.com
Sun Sep 3 09:54:03 EDT 2006
Tor Erik wrote:
> Tor Erik wrote:
>
>>Fredrik Lundh wrote:
>>
>>>Tor Erik wrote:
>>>
>>>
>>>>The reason is that my application does about 16 connects and data
>>>>transfers per second, to the same 16 remote hosts. After approx 200
>>>>secs there are 4000 sockets waiting to be garbage collected by the OS.
>>>
>>>what does "netstat" say about these sockets ?
>>>
>>></F>
>>>
>>They are in the TIME_WAIT state... The msn library has an article on how
>>to solve this:
>>
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS06CoreDocs/html/6987640c-1d80-4fbf-b43a-021fc8ba06a4.asp
>>
>>
>>Summing up one could either:
>>
>>1. Increase the upper range of ephemeral ports that are dynamically
>>allocated to client TCP/IP socket connections:
>>
>>set registry key:
>>KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort
>>
>>to a new DWORD value... (5000 - 65534)
>>The default in XP is 3976 -> http://support.microsoft.com/kb/Q149532
>>
>>or
>>
>>2. Reduce the client TCP/IP socket connection timeout value from the
>>default value of 240 seconds
>>
>>set registry key:
>>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay
>>
>>to a new DWORD value (30 - 300)
>>
>>The TCP RFC (RFC 793) recommends a value of 2*msl(Maximum Segment
>>Lifetime). The general consensus about the value of msn seems to be 1-2
>>minutes, depending on the underlying network... (2*2 min = 2*120 sec =
>>240 sec)
>>
>>
>>I do not want to alter my registry, so I'm currently testing an idea
>>where I let the client connect and send its content, appended with my
>>own "magic" EOF byte-sequence. When the server receives this EOF, it
>>takes care to close the connection. This should eliminate the problem as
>>it is the peer closing the connection that enters the TIME_WAIT state...
>>
>>I will report my experiences...
>
>
> Well... my idea does not work as expected. Even though the server
> (remote host) calls socket.close(), it is the client that executes
> TIME_WAIT. My guess is that the subtrates below socket closes the
> connection at the peer calling connect regardless of where socket.close
> is called.
>
> Thoughts anyone?
Yes, it's the transport layer that puts the socket into the TIME_WAIT state.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
More information about the Python-list
mailing list