Then why is file transfer via HTTP typically faster than with FTP?
Also, TCP does provide a mechanism for out-of-band messages within a si=
ngle
connection. (Not that HTTP makes any use of it, but telnet does.) "The=
asynchronous or "out-of-band" notification will allow the application t=
o go
into 'urgent mode', reading data from the TCP connection. This allows c=
ontrol
commands to be sent to an application whose normal input buffers are fu=
ll of
unprocessed data."
-Carl
ipp-owner@pwg.org on 02/12/98 12:40:15 AM
Please respond to ipp-owner@pwg.org @ internet
To: rturner@sharplabs.com @ internet
cc: ipp@pwg.org @ internet
Subject: Re: IPP> Does the world need a robust host-to-device network
Randy,
> I'm curious how this host-to-device protocol for printing would diffe=
r
> from IPP 1.0?
Excellent question. Right off the top of my head...
For one thing, such a protocol would be one heck of a lot more
efficient than IPP-over-HTTP. Anytime you frame bulk data within
a transaction protocol, you lose bigtime in terms of performance.
The CPAP designers learned this many years ago; the implementation
of an FTP-like side-band "data channel" is one of the big features
of CPAP v2. Also note that IEEE 1284.1 (aka "TIPSI", aka "NPAP")
added similar support for a separate data-only channel near the
end of that protocol's development.
In addition to the significant increase in performance, we found
that implementing such a protocol was a lot easier in terms of
structure and complexity. Always a nice win, to be sure.
Another way the protocol would differ from IPP is in the area
of async messages during the transaction. As the client submits
a job, the server can inform the client of any number of events
that occur during the transaction, such as device alerts and
other things the client may (or may not, granted) be interested
in.
Using CPAP as an example of this kind of protocol, CPAP has the
ability for the server to convey to the client that the client's
job was terminated (either via the front panel, or by a remote
management app communicating with the server). Furthermore,
the "job kill" message to the client can include exactly WHO
killed the job, thereby allowing the client to provide an
excellent level of detail to the job submitter as to why the
job failed.
There's more I can say here, but this is at least a start.
I anxiously await comments from others, particularly from you,
Randy! I'd really like to get this kind of thread rolling.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
=