W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: 'PUT' transaction reconsidered (was Re: two-phase send concerns )

From: Arjun Ray <aray@pipeline.com>
Date: Thu, 28 Dec 1995 13:53:27 -0500 (EST)
To: "David W. Morris" <dwm@shell.portal.com>
Cc: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.3.89.9512281346.A29041-0100000@alpha>



[Roy T. Fielding]
> write window eventually) instead of bitbucketing.  Unfortunately, I have
> no idea if this is portable across all TCP implementations, since closing
> only half a socket may be incorrectly implemented in some OS's.

[David W. Morris] 
> Not implemented may be more like the case. I can't find any reference
> in WINSOCK for example to closing 1/2 a connection.

shutdown().

TCP connections are full-duplex, and the ability to control each direction
separately is an integral part of the spec. (Each of the two paired
simplex "channels" are closed by sending a FIN packet to the other side.)
The classic example is where the server is a sort program reading data
from its standard input: it must have an end-of-data indication before it
can produce the sorted results that have to be conveyed back to the
client. The client achieves this by a half-close on its "write side",
leaving its "read side" open to retrieve the server's response. 

See RFC 793, Section 3.5 "Closing a Connection":

---8<---
  CLOSE is an operation meaning "I have no more data to send."  The
  notion of closing a full-duplex connection is subject to ambiguous
  interpretation, of course, since it may not be obvious how to treat
  the receiving side of the connection.  We have chosen to treat CLOSE
  in a simplex fashion.  The user who CLOSEs may continue to RECEIVE
  until he is told that the other side has CLOSED also.
---8<---

Any TCP implementation that does not support such full-duplex control 
(i.e. the TCP half-close) should be considered fundamentally broken.


Regards,

Arjun Ray
Received on Thursday, 28 December 1995 10:57:06 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:38 EDT