More questions on sockets

[Chris Torek]

>In article <1991Jun18.050654.17373 at thunder.mcrcim.mcgill.edu>
>mouse at thunder.mcrcim.mcgill.edu (der Mouse) writes:
>[Wait for closing sockets to close.]  As far as I can tell that's the
>only thing to be done.  

In article <CHRIS.91Jun18100547 at asylum.gsfc.nasa.gov>
chris at asylum.gsfc.nasa.gov (Chris Shenton) writes:
>I've encountered the same thing, and came up with the same non-fix. Any
>idea how long you have to wait (don't say ``until the port's free'' :-).
>Why?

Well, actually, it really *is* `until the port is free'.

There are two things going on:

 a) A TCP connection can be `half open': one side may be shut down while
    the other side still has the ability to send.  A TCP connection in this
    state could conceivably stay that way forever.  These are the FIN_WAIT
    states shown by netstat.

 b) Even when a TCP connection is `fully closed', the port should not be
    reused until any outstanding packets have timed out.  Otherwise one
    of these packets, lost somewhere in the network, might show up after
    a new connection is open and `sneak in'.  This timer is called TCP_2MSL
    internally; it stands for `2 times the Maximum Segment Lifetime'.
    It typically amounts to 30 seconds.

You can use SO_LINGER (which, N.B., changed between 4.2BSD and 4.3BSD)
to eliminate the second, but not the first.

One simple solution is to use a different port each time, along the
lines of the Sun RPC `port mapper'.  A single meta-server keeps track
of all active services.  To establish a service, you contact the port
mapper and say `I want to offer a service'.  It gives you a port
number.  When you are done you tell it `I no longer offer the service',
and it deletes that from its tables.  To obtain some service, you ask
the port mapper who to contact.  There are some races, but they tend
not to be too serious.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov