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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to