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@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@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 --
> >> ----------------------------------------------------------------------
> >>
> >
> >
> >