I don't see this as checkpointing. I would assume that the client retains
the data until it receives a response from the printer indicating that
it has received the data. Likewise the server would know the "high water"
mark for a file and ignore data below it.
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 at underscore.com Fri May 9 20:12:03 1997
> Date: Fri, 9 May 1997 23:10:07 -0400 (EDT)
> From: JK Martin <jkm at underscore.com>
> To: Robert.Herriot at Eng> Subject: Re: IPP>PRO another reason for needing byterange and document number
> Cc: ipp at 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 at pwg.org Fri May 9 23:07 EDT 1997
> Date: Fri, 9 May 1997 20:04:16 -0700
> From: Robert.Herriot at Eng.Sun.COM (Robert Herriot)
> To: ipp at 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 -----
>>