I welcome and appreciate this new analysis of possible solutions for
returning notifications to the IPP client.
It looks like we would be able to use at least one of the solutions
However, I like to remind people that using HTTP as notification mechanism
should be only ONE of the possible ways to do IPP notifications. For
notifications to other than the IPP job submitter, or in scenarios when it
might be hours before the notification comes back, we will need to provide
additional ways to deliver the notifications.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]
> Sent: Friday, June 18, 1999 11:25 AM
> To: email@example.com
> Subject: IPP> RE: Asynchronous updates/notifications
> From Scott Lawrence <firstname.lastname@example.org>
> >> From: email@example.com
> >> For some long-running operations, it would be nice if a server
> >> could send asynchronous notifications to a client, so the client
> >> doesn't have to poll (or refresh periodically) to get progress
> >> updates. I'm wondering if something similar to the 100-Continue
> >> mechanism could be used for this.
> >You can do this now by sending a single response with a
> >body. All it costs is keeping a connection open. The more
> general need is
> >for notifications that do not require an open connection,
> but that is a
> >different story.
> It looks like "server push", using the "multipart/mixed" MIME
> type, could go a
> long ways towards solving the IPP notification problem,
> within existing HTTP
> infrastructure. With server push, the server sends down a
> chunk of data; the
> client receives the data but leaves the connection open;
> whenever the server
> wants it sends more data and the client displays it, leaving
> the connection
> open; at some later time the server sends down yet more data
> and the client
> displays it; etc. [See
for more about server push and "multipart/mixed".]
Scenario: client submits job and wants to track its progress. This is
the most important and common scenario for IPP notifications.
1) Client polling: the client sends Get-Job-Attributes and maybe
Get-Printer-Attributes requests periodically to track the Job's progress.
Suppose the polling interval is 30 seconds. This is a compromise number
on trade-offs between getting timely updates to the client and efficiency.
a pretty lame compromise, though. Some existing systems can track the Job
progress on a page-by-page basis. You can't get that kind of granularity
polling at 30 seconds (unless you have a really slow Printer). But polling
30 seconds is also a disaster for efficiency. Suppose the client opens a
connection for each request. TCP (J. Postel, "Transmission Control
RFC 793) requires a server to remember connections for four minutes after
closing, in the TCP_WAIT state. So in steady state, a client polling the
at 30 second intervals is consuming eight connections worth of server
This can quickly become a limiting factor in the number of clients a Printer
support, which is important for situations when a Printer is a gateway to a
large print server normally capable of supporting a thousand clients. The
connection setup and teardown costs are large in terms of network bandwith
(something like 6 packets exchanged) and in server processor utilization.
Furthermore, having a large number of remembered connections (control
sort through slows down the server in processing incoming packets.
2) Client polling with persistent connections: this is a big improvement
1) in terms of efficiency. It's much cheaper for the server to remember one
connection indefinitely than to remember a new connection for at least four
minutes, every thirty seconds. An idle connection consumes no network
(possibly with the insignificant exception of keep-alive packets, which are
something like once every 2 hours), and the processor overhead of setting up
tearing down connections is avoided. Less server memory is used and the
has fewer control blocks to search through. This solution is still far from
ideal, however. The client still only gets updates at 30 second intervals.
server is pestered with requests every 30 seconds from each of possibly many
clients, and has to respond even if there is no news. Redundant request
are being sent from the clients.
3) Notifications via server push: after the client sumits a Job, (e.g., by
sending a Print-Job request), the Printer sends a mulipart/replace response.
The first "part" contains the normal IPP operation response. The connection
remains open, and as relevant events occur the Printer sends a stream of
additional parts containing (binary) IPP notifications back to the client.
the Job reaches a final state, the Printer sends the terminating boundary
indicating the end of the response. This solution puts a lot less load on
Printer and allows much more timely status updates to the client. This
mechanism is efficient enough that the Printer should be able to notify the
client as each page is printed. It could be extended to apply to other
operations. Polling could still be used for low-frequency status monitoring
say, Printer state.