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