[MUD-Dev] Re: Quick socket question
J C Lawrence
claw at under.engr.sgi.com
Mon Nov 9 17:56:49 CET 1998
On Sat, 07 Nov 1998 20:02:27 -0800
J C Lawrence<claw at kanga.nu> wrote:
> On Sat, 7 Nov 1998 15:06:42 -0600 (CST) Cat <cat at bga.com> wrote:
>> Anyway, I got a couple compatibility problems involving select()
>> and accept() worked out, but I've noticed the return of a problem
>> we sometimes had under Linux with the old DragonSpires server,
>> which is the ancestor of the Furcadia server code. After the
>> game is shut down or the server code crashes, and it tries to
>> restart, it fails to bind the port for the next 15-20 minutes.
> Yes. This is very very standard and actually even predictable.
> The exact causes (and I think the handling) are well documented in
> Steven's TCP/IP books (which are roughly 50 miles south of me
> right now, at work). Translation: Its in the book, I don't
> remember the details, I'll look it up on Monday if nobody does it
> before me.
Okay, the relevant passage in Steven's is on pages 242 thru 246 and
concerns the 2MSL Wait State. I'd quote it here except for its
length and my unwillingness to type that much before I leave.
In summary however (all typoes are mine):
"The TIME_WAIT state is also called the 2MSL wait sate. Every
implementation must chose a value for the "maximum segment lifetime"
(MSL). It is the maximum amount of time any segment can exist in
the network before being discarded. We know this time limit is
bounded, since TCP segments are transmitted as IP datagrams, and the
IP datagram has the TTL field that limits its lifetime.
...
"Given the MSL value for an implementation, the rule is: when TCP
performs an active close, and sends the final ACK, that connection
must stay in TIME_WAIT state for twice the MSL. This lets TCP
resend the final ACK in case this ACK is lost (in which case the
other end will time out and retransmit its final FIN).
"Another effect of this 2MSL wait is that while the TCP connection
is in the 2MSL wait, the socket pair defining the connection (client
IP address, client port number, server IP address, server port
number) cannot be reused. That connection can only be reused when
the 2MSl wait is over."
"Unfortunately most implementations (ie the Berkeley derived ones)
impose a more stringent constraitn. By default a local port number
cannot be reused while that port number is the local port number of
a socket pair that is in the 2MSL wait. ...
"(side note) Some implementations and API's provide a way to
bypass this restriction. With the sockets API, the SO_REUSEADDR
socket option can be specified. It lets the caller assign itself a
local port number that's in the 2MSL wait, but we'll see that the
rules of TCP still prevent this number from being part of a
connection that is in the 2MSl wait."
Ultimate translation: Run, do not walk, and go buy a copy of the
Steven's TCP/IP books. Read them. Study them. Sleep with them.
Treasure them. You will not regret it and you code will appreciate
it. If you want to save $$$, see:
http://www.bookpool.com/.x/nt34rcdnv8/ss/1?qs=TCP%2FIP+Illustrated
--
J C Lawrence Internet: claw at kanga.nu
(Contractor) Internet: coder at kanga.nu
---------(*) Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list