[comp.protocols.tcp-ip] 'shutdown' vs. 'close' to free resources?

toppin@melpar.UUCP (Doug Toppin) (10/18/89)

We have a problem with a large number of connections in
a short period of time exhausting the resources of the
host processor. I understand that after doing a close it
may be several minutes before the resources used by that
socket are completely freed for reuse and was wondering if
doing a shutdown would make any difference in the time
it takes to release all of the resources?
If anyone has an answer please let me know.
We are running Network Research Corp implemenation of TCP
(called Fusion) on IBM Xenix 2 on the 286.

thanks
Doug Toppin
uunet!melpar!toppin

dls@mentor.cc.purdue.edu (David L Stevens) (10/19/89)

	UNIX's shutdown(2) corresponds to the TCP ABORT function and is NOT
generally a good way to free socket resources, unless you have another way of
determining (through the upper level protocol) that no more data need be sent.
	In particular, if you do a shutdown(2) after you've written your data,
if the data is still in a kernel buffer on your end waiting to be sent, it will
be discarded and the other guy will never see it. Close(2) is the only way to
guarantee delivery of all pending written data short of doing this in the upper
protocol.
	In other words, close(2) isn't hanging onto everything just to be mean
to you... :-) It's where some of TCP's reliability comes from.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

michaud@decvax.dec.com (Jeff Michaud) (10/19/89)

> Close(2) is the only way to
> guarantee delivery of all pending written data short of doing this in
the upper
> protocol.

	Note that, at least in the OSI model, transport isn't really the right layer
	to do "orderly release".  "Orderly release" is a job for the OSI
Session layer.
	Since on the IP stack we really don't have a Session layer, it should be done
	in another higher layer (ie. the application protocol).  For example, both
	FTP and SMTP have an explicit release handshake.

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/