On Thu, 14 May 1998 14:04:02 -0700
Robert Herriot (robert.herriot@Eng.Sun.COM) wrote:
>
>...
>> > b) if a connection fails, there is no way to know if it because th=
e printer
>> > is down or just busy.
>>
>>Socket implementations typically provide for a "backlog".
>> The following program fragment illustrates the use of the listen sub=
routine
>> with 5 as the maximum number of outstanding connections which may
>> be queued awaiting acceptance by the server process.
>>
>> listen(s,5)
>Yes, and clients end up timing out when this listen queue is full. But=
'listen' is
>for TCP, and I am proposing a UDP solution for the printer status so t=
hat
>there is the least amount of overhead for the printer.
>
There is no such thing as a "connection" in UDP. I thought the
premise here was that one of Paul Moore's main problems that IPP
doesn't currently solve is that "if a connection fails, there is no
way to know if a it['s] because the printer is down or just busy".
My point is that with proper design, the connection should not
fail just because the printer is busy, unless it's so busy that
it might as well be considered down (i.e, in steady state, requests
are arriving at a rate faster than they can be satisfied).
-Carl
http://www.pwg.org/hypermail/sdp/0054.html
=
--Boundary=_0.0_=5030100020555212
Content-Type: application/octet-stream; name=SDPSugge.url
Content-Transfer-Encoding: base64
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9aHR0cDovL3d3dy5wd2cub3JnL2h5cGVybWFpbC9zZHAv
MDA1NC5odG1sDQpNb2RpZmllZD1BMEEzMTU2NjM4ODBCRDAxMzQNCg==
--Boundary=_0.0_=5030100020555212--