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