IPP> NOT - Requirements - still needs an accounting applicati on scenario

IPP> NOT - Requirements - still needs an accounting applicati on scenario

IPP> NOT - Requirements - still needs an accounting applicati on scenario

kugler at us.ibm.com kugler at us.ibm.com
Wed Jul 21 17:14:44 EDT 1999


 <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




More information about the Ipp mailing list