Re: PUT

   From: Roger Gonzalez <rg@server.net>
   Date: Tue, 26 Sep 1995 10:55:05 -0400
   Cc: rg@server.net

 > 1) Status is returned immediately after the request, and no
 >    status is returned to signify the success of the entity transfer.
 > 2) Failure status is returned as soon as a failure occurs.  Success
 >    status is never returned until the very end of the entire
 >    transaction.
 > 3) All status is returned at the completion of the entire transaction.
 >    The server is required to eat (and probably discard) any data the
 >    client sends, even if it failed.

 > Option 2 requires much hairier client and server code.  It seems to me
 > that everything would require nonblocking i/o, in order to constantly
 > check to see if reading or writing is possible.

If you have code for the client to abort a persistent connection by
sending a TCP URP, then option 2 becomes fairly simple.  It's
essentially the same, except in the opposite direction.

The server sees an error (say available storage is at the low water
mark).  It sends a TCP URP to the client.  The client goes into
"urgent mode" and aborts its transmission, then sends a transmission
abort back to the server.  The reason for the client to send an abort
back to the server in return is that the client needs to flush any
further requests sent to the server when the server says stop!.  It
also resets the server to a known state (i.e. known to the client).

As soon as the client has sent the URP, it _knows_ the server is
synchronized when it has processed the URP, and the client can happily
continue sending commands.

For an example on how TCP URP is used to abort an in-progress
transmission in either direction, look at FTP.  (It hangs up the data
connection, but that's integral to how FTP works.  http wouldn't have
to, the interesting concept is flushing the control connection up to
the TCP URP mark.)

 > Any thoughts?  Hypermail pointers for me?

My thought is that the problem is the same as aborting a transmission
from server to client on a persistent connection without
disconnecting.  Only this time it's the client that's aborted by the
server.  Again, disconnecting will most likely just require an instant
reconnect.

rlogin has some ugly cruft to pass window size changes.  It sends a
TCP URP, then the magic sequence "\0377\0377ss" followed by a 12-byte
status block.  http could use a similar approach: whenever a
transmission is aborted, it sends the TCP URP followed by a diagnostic
message (marked-up or plain text, not binary goo like rlogin).

Anyway, just my thoughts on the matter...

						-- Jan Brittenson
						   bson@eng.sun.com

Received on Tuesday, 26 September 1995 15:25:14 UTC