original article:http://www.egroups.com/group/ipp/?start=6169
> > 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.
Can't we depend on TCP's Nagle algorithm to do this coalescing for us?
>> 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.
Why would the receiver acknowledge each packet? I thought the receiver
was supposed to ack the longest contiguous prefix of the stream that
has been received correctly -- a cumulative acknowledgement scheme.
Therefore there may only be one ACK for multiple segments transmitted.
I thought one ACK for two segments is typical.
> 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