Subject: Re: Q: PLT/mzscheme socket question
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 8 May 2001 03:56:38 GMT
Newsgroups: comp.lang.scheme
Message-ID: <9d7qpm$6f37c$1@fido.engr.sgi.com>
Matthew Flatt  <mflatt@cs.utah.edu> wrote:
+---------------
| Mark Watson wrote:
| > Problem: the close-[input,output]-port procedures don't
| > seem to really be closing the input/output ports created
| > in the call to tcp-acept.
+---------------

Actually, they are. Really. (I added some code to your example
that tried to output to "out-port" after it was closed. Error!)

+---------------
| If netstat is showing TIME_WAIT - and I expect that it is...
+---------------

It is. I duplicated his example here:

    % netstat | grep TIME
    tcp        0      0  serverhost.9199   clienthost.20507        TIME_WAIT   
    tcp        0      0  serverhost.9199   clienthost.20508        TIME_WAIT   
    tcp        0      0  serverhost.9199   clienthost.20509        TIME_WAIT   
    % 

+---------------
| ...then the effect you see is inherent to TCP.
| There's nothing you can do to avoid the delay without
| weakening the protocol.
+---------------

Yup. Exactly. From RFC 761:

    TIME-WAIT - represents waiting for enough time to pass to be sure
    the remote TCP received the acknowledgment of its connection
    termination request.

And the timeout for moving from TIME-WAIT -> CLOSED is 2*MSL, that is,
twice the "maximum segment lifetime", which is by default is two minutes.
[So 2*MSL is 4min.]

If you do a web search, you'll surely find some hints for web servers
concerning tuning parameters (such as the estiomate of MSL) which you
can tweak in some operating systems -- which *violate* the RFCs -- but
which make the server perform better when being used for *huge* numbers
of short TCP connections per second. However, as Mathhew points out,
these tweaks *do* weaken the protocol against certain erroneous conditions
(some of which can be exploited by attackers). So don't do that unless
you *must*.

Plus, most "modern" TCP implementations implement the TIME-WAIT ->
SYN-RCVD transition described in RFC 1122, section 4.2.2.13:

            When a connection is closed actively, it MUST linger in
            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
            However, it MAY accept a new SYN from the remote TCP to
            reopen the connection directly from TIME-WAIT state, if it:
 
            (1)  assigns its initial sequence number for the new
                 connection to be larger than the largest sequence
                 number it used on the previous connection incarnation,
                 and
 
            (2)  returns to TIME-WAIT state if the SYN turns out to be
                 an old duplicate.

This allows re-use of the PCB (protocol control block) before 2*MSL has
expired, and makes the situation you describe largely a non-problem
(except for seeing all the PCBs cluttering up the "netstat" output).


-Rob

-----
Rob Warnock, 31-2-510		rpw3@sgi.com
SGI Network Engineering		<URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA