As you also have demonstrated, the optimal transport protocol depends
greatly upon the scenario expected. TCP would be a better choice if a
large number of notifications would be expected over a short period of
time. In general, this should not be true for printers. The exception
case is page completion notifications. My point is, if these are simply
UDP without an acknowledgement, then the number of notifications that
require feedback drops significantly. With notifications few and far
between, only the subscriptions that persist over many jobs would benefit
from TCP. For a single job subscription, only the job completed event and
the occasional error report should require an ACK. So the issue becomes,
do you want continuous TCP connections.
I am not trying to dictate the transports to be used. This is just to
demonstrate that multiple transports need to be provided in the
specification. We can either specify which combinations are to be
supported or let the developer decide based upon his perceived scenarios.
Ron Bergman
Hitachi Koki Imaging Solutions
On Wed, 21 Jul 1999 kugler@us.ibm.com wrote:
> <pine.wnt.3.96.990720083124.106d-10000-@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
>
>