>From Scott Lawrence <lawrence at agranat.com>
>> From: kugler at us.ibm.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 multipart/replace
>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 http://www.netscape.com/assist/net_sites/pushpull.html
for more about server push and "multipart/mixed".]
Scenario: client submits job and wants to track its progress. This is probably
the most important and common scenario for IPP notifications.
Solution alternatives:
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 based
on trade-offs between getting timely updates to the client and efficiency. It's
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 at
30 seconds is also a disaster for efficiency. Suppose the client opens a new
connection for each request. TCP (J. Postel, "Transmission Control Protocol",
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 server
at 30 second intervals is consuming eight connections worth of server memory.
This can quickly become a limiting factor in the number of clients a Printer can
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 blocks) to
sort through slows down the server in processing incoming packets.
2) Client polling with persistent connections: this is a big improvement over
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 bandwidth
(possibly with the insignificant exception of keep-alive packets, which are sent
something like once every 2 hours), and the processor overhead of setting up and
tearing down connections is avoided. Less server memory is used and the server
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. The
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 packets
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. When
the Job reaches a final state, the Printer sends the terminating boundary string
indicating the end of the response. This solution puts a lot less load on the
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 types of
operations. Polling could still be used for low-frequency status monitoring of,
say, Printer state.
Comments?
-Carl