Classification:
Scott, thanks for your response. Just a couple of things:
1) Could you provide a short scenario of how using byte ranges would work for
recovery when sending very large files for those of us who are novices in http?
That would be genuinely helpful.
2) I can see in your response to my last question see how shutting down the
connection signals some problem, but I'd like to be able to tell the client
what the problem is!
Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/02/97 10:52
AM ---------------------------
lawrence @ devnix.agranat.com
04/30/97 11:44 AM
To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org at internet
Subject: Re: IPP>PRO - things that worry me
>>>>> "RKD" == Roger K Debry <rdebry at us.ibm.com> writes:
RKD> As we close in on the definition of the protocol, there
RKD> are still some things that worry me.
RKD> 1) Will our proposed use of http handle the transport of
RKD> very very large (many Gbyte) files efficiently and with sufficient
RKD> recovery? I know you all have tried to convince me that tcp/ip
RKD> provides everything that is necessary to guarantee delivery,
RKD> but I still am concerned that we may have left holes where
RKD> a connection remains open because of some failure, or some
RKD> component times out, the print file does not get delivered and
RKD> no one knows why or how to recover because there is no ipp
RKD> level notification of what has happened.
I don't understand what you believe is missing. The file would be
sent as (part of) the body of an HTTP POST, which only acknowleged
when the entire body has been received and understood.
As to sufficient recovery, for files of that size you might want to
consider the use of multipart/byterange to break up the file so that
you can avoid resending the entire file following some failures.
This does not require any HTTP/1.1 change that I can think of.
RKD> 2) Have we sufficiently handled the case where a print driver is
RKD> generating the print ouput and putting it on the wire a piece at
RKD> a time? Does chunking solve this problem?
If the problem you refer to is not knowing how big the content is at
the time you are generating the HTTP headers, then yes, chunking
does solve that problem.
RKD> 3) Have we sufficiently handled the case where ipp is implemented
RKD> in an output device that has no capability to spool the data so must
RKD> start printing while receiving the data? What happens when a printer
RKD> failure occurs during transmission in this case?
The printer (in its role as HTTP server) will not have sent an
acknowlegement of the POST yet. When the failure occurs, it can
prematurely close the TCP connection. The client will (correctly)
interpret this premature close as an error in the server and will
know that the POST has not occured (ie the file has not been
printed).
--
Scott Lawrence EmWeb Embedded Server <lawrence at agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/