Subject: FW: IPP> NOT - device-to-host events, not end-user events

From: "Turner, Randy" <[email-masked]>
Date: Wed, 11 Mar 1998 13:30:35 -0800

-----Original Message-----
From:	Turner, Randy 
Sent:	Wednesday, March 11, 1998 1:30 PM
To:	'Jay Martin'
Subject:	RE: IPP> NOT - device-to-host events, not end-user
events

I agree with Jay completely. It would be very difficult for me to agree
any more on this....but I'll try. ;)

Randy.

	-----Original Message-----
	From:	Jay Martin [SMTP:[email-masked]]
	Sent:	Wednesday, March 11, 1998 10:43 AM
	To:	Tom Hastings
	Cc:	[email-masked]
	Subject:	Re: IPP> NOT - device-to-host events, not
end-user events

	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:   [email-masked]
--
	--  Underscore, Inc.        |  Voice:   (603) 889-7000
--
	--  41C Sagamore Park Road  |  Fax:     (603) 889-2699
--
	--  Hudson, NH 03051-4915   |  Web:
http://www.underscore.com   --

----------------------------------------------------------------------

---

From: Jeff Schnitzer <[email-masked]>
Date: Thu, 12 Mar 1998 12:02:23 -0500

[Roger accidentally sent this to ipp-owner rather than [email-masked]]

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 <[email-masked]>
     To: <[email-masked]>

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: [email-masked]
phone: 1-303-924-4080

> [email-masked] on 03/12/98 09:09:05 AM
> To: [email-masked] @ internet
> cc: [email-masked] @ internet, [email-masked] @ internet, [email-masked] @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:   [email-masked]          --
> --  Underscore, Inc.        |  Voice:   (603) 889-7000              --
> --  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
> --  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
> > 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
> > >> 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
> > >> --  JK Martin               |  Email:   [email-masked]          --
> > >> --  Underscore, Inc.        |  Voice:   (603) 889-7000              --
> > >> --  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
> > >> --  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --