Re: Closing sockets does not free them

Dear Nicolas,

many thanks for this comprehensive answer, it helps a lot! Will try
playing with the options you mentioned.

Cheers,
Lars

Nicolas Pelletier wrote:
> Hello,
> 
> On Wed, Sep 2, 2009 at 00:41, Lars Frantzen<[email protected]> wrote:
>> I have written a simple server written in GNU Prolog opening a socket
>> for a client. After the job is done I close the streams and terminate
>> the program.
>>
>> However, after terminating, the socket stays blocked for some time (like
>> 2 minutes), I get a:
>>
>> system_error(cannot_catch_throw(error(system_error('Address already in
>> use'),socket_bind/2)))
> 
> This is perfectly normal behaviour for a TCP socket. :-)
> 
> When a TCP socket is closed, it still lingers for some time to allow
> for traffic that would still be directed at it and "on the fly"
> somewhere in the network to die out before the socket can be
> reallocated. If this were not so, quickly closing and re-opening a
> socket bound to the same address and port would let it received
> traffic that was part of the previous (and now irrelevant) stream.
> 
> The recommended, standard, and default time-out is 2 minutes. However,
> when using fast networks and/or many TCP connections, this safety
> time-out may come as a performance bottleneck (It is still quite
> common to mistake the number of TCP connections established per second
> for a measure of the actual TCP stack performance). This parameter is
> usually settable; under Linux, man 7 tcp and the parameters in
> /proc/sys/net/ipv4 will let you tweak this. Specifically,
> 
>        tcp_tw_recycle (Boolean; default: disabled)
>               Enable fast recycling of TIME_WAIT sockets.  Enabling
> this option is not recommended since this causes problems when working
> with  NAT  (Net‐
>               work Address Translation).
> 
>        tcp_tw_reuse (Boolean; default: disabled)
>               Allow  to  reuse  TIME_WAIT  sockets  for  new
> connections  when  it  is  safe  from  protocol  viewpoint.  It should
> not be changed without
>               advice/request of technical experts.
> 
> However, be prepared to debug strange network behaviour if you turn
> the knobs without knowing what they do.
> 
> Hope this helps,
>