Path: utzoo!utgpu!news-server.csri.toronto.edu!hub.toronto.edu!thomson
Newsgroups: comp.protocols.tcp-ip
From: thomson@hub.toronto.edu (Brian Thomson)
Subject: Re: Questions on TCP shutdown and RFC-793
Message-ID: <1990Dec10.131116.19393@jarvis.csri.toronto.edu>
Organization: University of Toronto
References: <36540017@hpindwa.cup.hp.com> <2452@mentor.cc.purdue.edu>
Date: 10 Dec 90 18:11:16 GMT
Lines: 30

In article <2452@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>	Re: shutdown(2) in BSD implementations. It corresponds roughly to
>the TCP ABORT function, but not quite. In particular, as the manual page
>says, any buffered data pending will be dropped. It isn't really the
>"half close" that RFC 793 wants, and it should only be used in programs
>that are aborting or, because of mechanisms in the application protocol,
>already know that the data has been delivered. It should *not* be used for
>applications that have done writes and just want to mark the end of data for
>the peer, since any data still pending in the local send buffers is discarded
>and never delivered.

I think the original question was about the TCP shutdown procedure, not the
BSD shutdown() system call, but this answer caught my attention because it
seems to contradict everything I thought I knew about the BSD routine.
My understanding is as follows:
	shutdown(s, 0)	- flushes data queued for receive, and shrinks
			  my receive window to zero.  Succeeding reads will
			  fail.
	shutdown(s, 1)	- data already queued will be delivered, followed
			  by a FIN.  Succeeding writes will fail.
	shutdown(s, 2)	- equivalent to { shutdown(s, 0); shutdown(s, 1); }

The second of these is precisely the orderly half close.
None of them performs the TCP ABORT function.

And, to top it off, my manual pages (Sun) say nothing about loss of
buffered data pending.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu