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