<pine.wnt.3.96.990720083124.106d-10000- at rbergm.dpc.com> wrote:
original article:http://www.egroups.com/group/ipp/?start=6017
...
>> I am now convinced that the transport selected should be a function
of the
> notification type and we should not allow any notification on any
> transport. For example, the page complete notification should be
only a
> UDP without acknowledgement. If page completions are lost its not a
big
> deal, the next notifcation will bring you up-to-date. For Job
Completion,
> Job Statistics, or Errors a reliable transport should be required in
most
> cases. For these I believe that TCP is an overkill. UDP with
> acknowledgement is more than adequate. Congestion control should not
be
> an issue.
>
I agree that congestion control should not be an issue. In fact, I
can't imagine how TCP would be of any help at all for network
congestion control in this application. However, I disagree that TCP
is overkill compared to UDP with acknowledgement. UDP with
acknowledgement is likely to be more expensive in network bandwidth
than TCP on a persistent connection. (TCP doesn't ack every packet
individually.) On the other hand, maintaining lots of connections could
become a limiting factor to the number of clients a Printer can
support, if thousands of clients just stay connected forever.
I like the idea of using in-band (HTTP/TCP) "server push" for
rapid-fire, page-complete-type notifications, and something else for
lower-frequency notifications. This is the virtually only way to get
Job status notifications back through firewalls, and should be
super-efficient since you've already opened a connection for the
Print-Job request and response. I think this class of notifications
(i.e., job status) is probably the most important in IPP, and is worth
optimizing.
I think in-band notifications would meet the needs of Job Submitting
End Users, and persistently connected TCP is okay for Operators and
Administrators since there are presumably few of them.
-Carl