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