Re: PUT

In a previous missive, I sez:

> 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.

I wasn't clear about what I meant here.  I didn't mean to imply that
nonblocking i/o is hairy, although it sure reads that way.  I've
gotten several messages to the effect that noblocking i/o isn't that
hard.  I realize, thanks.  :-)  

I'm not sure what I meant.  I think I was referring more to the issue
that many simple HTTP programs just do blocking I/O, and that making
everyone have to perfectly monitor the network link
readability/writability makes the minimum buy-in to the protocol much
more complicated.  I know of several HTTP libraries in several
languages that would immediately need to be rewritten or heavily
modified.

(But, as was pointed out, it really only needs to be done on the client
side.)

Since my "Option 2" is closest to what I have implemented, let me
describe it:

Server-side:

1)  Upon detecting an error, the server immediately sends out a
    failure status.

2a) Server closes port (with default linger).  (This works fine for 
    Unix clients, which get a SIGPIPE, and are able to read the
    rest of the data.  Windows clients freak out and trigger a TCP
    reset, losing whatever data was pending for them to read.)

-or-

2b) Server eats bytes until client closes.  (My recent fallback hack.)

Client-side:

1)  Client assumes that all will go well, and sends out request.
    It does a check to see if there's anything to read, but since
    network latency is working against it, there's almost never
    anything there yet.  So, it starts the PUT.

2)  Before sending each block of the entity, the client checks for
    status to read.  If it reads failure, it aborts the send, and
    closes, perhaps to try again in a later connection with
    authentication or whatever.

Why I'm not fond of this implementation:

The server is vulnerable to a poorly implemented client.  It must
either stay open, or absorb crap being sent to it.  Neither is an
optimal use of resources.

Using icky magic timers look like they would help with this, but
they then just make the protocol potentially unusable over a bad
net connection.  In any case, the result of using a timer would be 
that the server would just disconnect, leaving both the client in
the dark about the error, and the server unsure of whether the
information actually got to the client.

These aren't necessarily a big deal for human-driven transactions (we
all have experienced how losing TCP can be, and how just clicking
"reload" in the browser can often grab something faster than waiting
for a wedged transfer.)

But, it significantly increases the difficulty of using HTTP in a
fully automated fashion.  Either the server doesn't know what happened
to the client, or the client doesn't know what happened to the server.
Either way, their only recourse is to retry the transaction.  If the
network is being nasty to them, the results may well be equally
ambiguous.

In a protocol implementation, I don't like having ambiguous scenarios.
Everything should be nice and predictable and deterministic.

Thus my point about requiring two status messages, one after the
request, and one after the entity.

I'm actually going to try implementing the scheme Roy devised with
the 100 Info messages.  I'm sure it will clean up my implementation.

I'll keep you posted.  :-)

-Roger

Roger Gonzalez                    NetCentric Corporation
rg@server.net                     56 Rogers Street
home   (617) 863-0705             Cambridge, MA 02142
mobile (617) 755-0635             work (617) 868-8600



60 09 3A EE FE 6A 1E CC   -pgp-   B7 F7 6B 0F 00 1D 01 C7

Received on Tuesday, 26 September 1995 16:19:51 UTC