[Roger accidentally sent this to ipp-owner rather than ipp at pwg.org]
Subject: Re: IPP> NOT - device-to-host events, not end-user events
Date: Thu, 12 Mar 1998 11:52:23 -0500
From: Roger K Debry <rdebry at us.ibm.com>
To: <ipp-owner at pwg.org>
In IPDS we defined some data stream level constructs to return
information about the state of the printer. However, we do not use
these for flow control, which should be handled by the transport.
However, we find these data stream constructs *VERY* useful in
resynchronizing the printer with the server in the case of some error
conditions.
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
>ipp-owner at pwg.org on 03/12/98 09:09:05 AM
> To: hastings at cp10.es.xerox.com @ internet
> cc: ipp at pwg.org @ internet, rbergma at dpc.com @ internet, paulmo at microsoft.com @internet
> Subject: Re: IPP> NOT - device-to-host events, not end-user events
>>> Tom,
>> No, most (all?) TCP stack implementations do not expose
> data throttling events to the client. (That is one of
> the several "transparent" things the stream-like TCP
> design gives the client.)
>> While it wouldn't be trivial, I suppose a client app could
> make some thread priority adjustments based on detecting a
> "blocked" outbound stream. That is, upon trying to send a
> buffer, the client would reduce the thread priority if the
> API write function returned the (UNIX) equivalent of EWOULDBLOCK
> (assuming the socket was setup for non-blocking I/O support).
>> While I understand Paul Moore's situation, I still don't think
> it's a good idea to introduce this kind of communications
> status in an application-level protocol such as IPP.
>> Does anyone disagree?
>> ...jay
>> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm at underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>>> Tom Hastings wrote:
> >
> > At 11:10 03/11/1998 PST, Ron Bergman wrote:
> > >Tom,
> > >
> > >I certainly agree with Jay on this subject. I don't know of any transport
> > >that does not provide some method of flow control. Certainly TCP provides
> > >an excellent flow control mechanism.
> > >
> > >I don't recall this requirement discussed in any of the meetings in
> > >Austin. Where did this come from?
> >
> > Paul Moore suggested this. It is NOT flow control but rather
> > advisory to a host that is controlling a large number of devices
> > at once. Paul says he has NT systems that control a large number of
> > devices, like 500, so that knowing which devices the host is getting
> > ahead and which devices the host is falling behind in getting PDL data
> > to the device would be useful. My understanding of what Paul was saying
> > was that the host would then increase the priority of the threads that
> > were getting behind and lower the priority of the threads that were
> > getting ahead.
> >
> > Or does TCP/IP have such advisory events (as opposed to stop sending
> > and start sending)?
> >
> > Tom
> >
> > >
> > >
> > > Ron Bergman
> > > Dataproducts Corp.
> > >
> > >
> > >On Wed, 11 Mar 1998, Jay Martin wrote:
> > >
> > >> Tom Hastings wrote:
> > >> >
> > >> > In discussing the host-to-device requirements, we came up with a
> > requirement
> > >> > that the printer be able to feed back information about whether it was
> > >> > choked up with data or needed more data for the current job.
> > >> >
> > >> > So we could have events like:
> > >> >
> > >> > Slow down data transfer
> > >> > Speed up data transfer
> > >>
> > >> This doesn't quite sound right. I mean, flow control should be mandated
> > >> by the underlying transport, right? We certainly don't want to reinvent
> > >> such a key aspect of end-to-end communications within IPP.
> > >>
> > >> ...jay
> > >>
> > >> ----------------------------------------------------------------------
> > >> -- JK Martin | Email: jkm at underscore.com --
> > >> -- Underscore, Inc. | Voice: (603) 889-7000 --
> > >> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> > >> -- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
> > >> ----------------------------------------------------------------------