I think that I am talking about something different. I am talking about the
case where a print server fails when it has partially received data. The
previously received data remains intact.
When the client makes contact with the server, the server resumes
building the data files for the job at the point where it left off.
If this were an IPP printer instead, I think the issue is the same
except that the printer may have already printed a partial page so that
the new data may start another partial page.
I think that you are seeing some problem that I am missing.
Bob Herriot
>
> ----- Begin Included Message -----
>
> From ipp-owner@pwg.org Fri May 9 23:41 EDT 1997
> Date: Fri, 9 May 1997 20:38:27 -0700
> From: Robert.Herriot@Eng.Sun.COM (Robert Herriot)
> To: Robert.Herriot@Eng.Sun.COM, jkm@underscore.com
> Subject: Re: IPP>PRO another reason for needing byterange and document number
> Cc: ipp@pwg.org
>
> 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@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 -----
> >
> >
>
>
> ----- End Included Message -----
>
>