The question is whether the client should retransmit the failed
operation or figure out how to start the sequence all over again. I am
suggesting the NFS and Web NFS algorithms when I suggest retransmitting
the failed operation.
Do you really think it is easier for both client and server to restart
the sequence of operations?
Bob Herriot
> From jkm@underscore.com Fri May 9 20:12:03 1997
> Date: Fri, 9 May 1997 23:10:07 -0400 (EDT)
> From: JK Martin <jkm@underscore.com>
> To: Robert.Herriot@Eng
> Subject: Re: IPP>PRO another reason for needing byterange and document number
> Cc: ipp@pwg.org
> X-Sun-Charset: US-ASCII
> Content-Length: 2240
> X-Lines: 57
>
> Is IPP expected to support checkpointing to the point where the
> client will resume submission of document at *precisely* the point
> where the transmission failed?
>
> I wouldn't think so. Rather, the client would resume transmission
> at the *start* of the document that failed.
>
> Is this true?
>
> ...jay
>
> ----- Begin Included Message -----
>
> From ipp-owner@pwg.org Fri May 9 23:07 EDT 1997
> Date: Fri, 9 May 1997 20:04:16 -0700
> From: Robert.Herriot@Eng.Sun.COM (Robert Herriot)
> To: ipp@pwg.org
> Subject: IPP>PRO another reason for needing byterange and document number
>
> After reading through the WebNFS document and spotting the following paragraphs,
> I think we need byteranges and document numbers.
>
> 10.0 Timeout and Retransmission
>
> 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
>
>
> ----- End Included Message -----
>
>