Thanks for your reply. I have a few more questions.
In your example of HTTP notification below, you don't provide a way of
specifying which events are of interest. The document
http://search.ietf.org/internet-drafts/draft-wolf-http-select-00.txt
describes a mechanism using http that subscribes to events and then listens
for them.
Does that document describe a mechanism that you think it reasonable?
Do you think that IPP should support both an http mechanism (such as the one
described in the IETF draft) and a tcp one, where the receiver listens on a
port?
At the IETF IPP session, we discussed congestion control as a reason for
preferring TCP over UDP, but you didn't mention in your email. Do you still
believe that it is a reason to prefer TCP, at least for the page completion
case.
Bob Herriot
-----Original Message-----
From: Keith Moore [mailto:moore at cs.utk.edu]
Sent: Friday, August 13, 1999 7:13 PM
To: Herriot, Robert
Cc: Keith Moore; ipp
Subject: Re: IPP>MOD Should IPP notification use http as transport?
> I asked you about using http as the transport. You suggested that I
> send you email to get your comments on the pros and cons of http as
> the event transport.
basically, you don't want to use http (or any tcp based protocol)
to send small payloads, because the connection setup overhead
is fairly large, and also because tcp connections that are being
established do not compete fairly with tcp connctions that are
already established (under very loaded conditions, attempts to
establish new connections can steal bandwidth from
already-eastablished connections)
but a lot depends on how you use http or tcp.
if you know you're going to be sending several short status updates
(say, per-page acknowledgements) and the duration of the session is
such that you can probably keep a single tcp connection open for the
entire time, and especially if you need reliable delivery of those short
messages (i.e. you can't afford to have a status update dropped
or delivered out-of-order) it's probably reasonable to open a tcp
connection and deliver each update over the connection. but you
want to try to do this not only in a single tcp session, but also
in a single http transaction. i.e. you should avoid introducing
extra http round-trips. e.g. do something like this:
(connection opened)
>>> GET /printer/status/job#2343 HTTP/1.1
>>><<< Content-type: application/ipp-status-messages
<<<
(pause)
<<< status: page 1 printed
(pause)
<<< status: page 2 printed
(pause)
<<< status: page 3 printed
(pause)
<<< status: out of paper
(pause)
<<< status: resumed
(pause)
<<< status: page 4 printed
<<< status: job complete
(connection closed)
rather than sending a separate GET or POST or whatever for each
transaction reported. and you really want to avoid
opening up a new tcp connection for every page printed.
you can save a bit more bandwidth by batching status updates,
and only sending a single update (perhaps for multiple pages)
every N seconds, or when an exception occurs, whichever
is sooner.
if you're doing per-page status updates, you're going to
be sending at least one packet per page regardless of whether
you use TCP or UDP. the difference would be that each packet
sent in TCP would be acknowledged by the receiver, in
most cases doubling the number of packets sent over the link.
for most kinds of links you are concerned about minimizing
bandwidth (rather than packets) or delay (to improve response
time for interactive applications). the latter doesn't apply
in this case. as for users of links that charge per-packet,
they can avoid the problem by not requesting per-page status updates.
if you're doing less frequent notifications (like job completion
notifications), the volume of data is less, but in this you probably
do want reliable delivery and acknowledgement. an RPC-like protocol
layered on UDP would work. but if you're only sending a single
notification per print job, it's probably not worth the savings.
so offhand, as long as IPP notifications can nearly always occur in a
single TCP session and a single HTTP transaction per print job
(and especially if it can be piggybacked in the same HTTP/TCP session
used to submit the print job), I can't make a strong case for using
UDP for IPP notifications, or even for supporting it as an option.
of course, if there's an important case that I'm missing, let me know.
(just in case the http session gets disconnected, you probably will
want to have the capability of reconnecting, but it should be
the exception rather than the rule. and you need to define what
happens in this case - do you replay all status messages since
the start of the print job or do you just replay those issued after the
start of that http session?)
hope this helps,
Keith