Bob, I'm glad that someone else finally realizes that we need
something in the IPP layer to help with recovery. If you would
go back to the protocol proposal that I presented in the San
Jose PWG meeting, you will see that what we are getting very
close to that proposal. However, that proposal used a
sequence number, rather than byte range. I believe that
byte range is definate overkill, and a sequence number
would be simpler (especially for a re-director) to
generate.
Bob Berriot Wrote:
> A WebNFS client should follow the example of conventional
>NFS clients and handle server or network outages gracefully.
>If a reply is not received within a given timeout, the client
>should retransmit the request with its original XID (described
>in Section 8 of RFC 1831). The XID can be used by the server
>to detect duplicate requests and avoid unnecessary work.
>While it would seem that retransmission over a TCP connection
>is unnecessary (since TCP is responsible for detecting and
>retransmitting lost data), at the RPC layer retransmission is
>still required for recovery from a lost TCP connection, perhaps
>due to a server crash or, because of resource limitations, the
>server has closed the connection. When the TCP connection
>is lost, the client must re-establish the connection and
>retransmit pending requests. It seems to me that this same issue
> exists with regard to IPP operations including those that send
>document data. Thus a client may send a block of document
>data where the transmission succeeds at the TCP level, but
>the server crashes before sending a "data received and
>processed" reponse. In such a case, the server may or may
>not have processed the data. Since the client will have to
>retransmit the data, the server needs to know whether it is new
>data or another copy of the last data, thus the need for byte ranges
>and document numbers to identify the piece of data.
>Comments?
>Bob Herriot