IPP>PRO another reason for needing byterange and document number

IPP>PRO another reason for needing byterange and document number

IPP>PRO another reason for needing byterange and document number

JK Martin jkm at underscore.com
Fri May 9 23:10:07 EDT 1997


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


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



More information about the Ipp mailing list