IPP> RE: Asynchronous updates/notifications

IPP> RE: Asynchronous updates/notifications

kugler at us.ibm.com kugler at us.ibm.com
Fri Jun 18 14:51:34 EDT 1999



I agree.  I just think that HTTP server push looks attractive for an important
class of notifications.  It could be combined with email and polling, too.

     -Carl



"Manros, Carl-Uno B" <cmanros at cp10.es.xerox.com> on 06/18/99 12:45:06 PM

To:   Carl Kugler/Boulder/IBM at IBMUS, ipp at pwg.org
cc:
Subject:  RE: IPP> RE: Asynchronous updates/notifications





Carl,

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
described.

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.

Carl-Uno

> -----Original Message-----
> From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
> Sent: Friday, June 18, 1999 11:25 AM
> To: ipp at pwg.org
> Subject: IPP> RE: Asynchronous updates/notifications
>
>
>
>
> 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








More information about the Ipp mailing list