--=====================_7260730==_.ALT
Content-Type: text/plain; charset="us-ascii"
Notification does not handle the case where a connection or a 'write' times
out and the client (print server) want to determine if the printer is
currently alive and making progress. The client (print server) needs to
perform a "get printer status" operation immediately and not wait until some
future notification arrives. The "get printer status" operation must give a
reply
(with a high probability) if the printer is alive.
Bob Herriot
At 01:34 PM 5/14/98 , Harry Lewis wrote:
>Bob stated...
>>>The concern I have about SNMP is that a client's "get status" query could >be
>behind several GetBulk requests and thus not get processed fast enough >for
the
>client to determine that the printer is alive but very busy.
>>This is one reason notifications are useful rather than polling.
>>Harry Lewis - IBM Printing Systems
>>>>owner-sdp at pwg.org on 05/14/98 01:43:48 PM
>Please respond to owner-sdp at pwg.org>To: robert.herriot at Eng.Sun.COM, jkm at underscore.com>cc: sdp at pwg.org>Subject: Re: SDP> Suggestions for discussion at SDP session next week
>>>In my solution, I assume that there is a port dedicated to returning printer
>status only and it has higher priority for processing than the normal IPP
>port or the SNMP port. I want to keep the probability of a reply near 100%
>even when the printer is very busy with other network requests.
>>The concern I have about SNMP is that a client's "get status" query could be
>behind
>several GetBulk requests and thus not get processed fast enough for the client
>to
>determine that the printer is alive but very busy.
>>Can an SNMP request have as good a guarantee of a quick response as a
>dedicated port?
>>Also in my proposal, I assume that the data returned is in an IPP compatible
>format.
>>Bob Herriot
>>At 08:15 PM 5/13/98 , Jay Martin wrote:
>>Regarding solution "b":
>>>>> b) the primary issue is being able to determine the printer status,
i.e.
>>> did the connection fail because the printer is down or just busy.
>One
>>> simple solution is to have a printer read on a UDP port dedicated
to
>>> returning a status summary whenever it receives a request on the
>port. If
>>> the incoming bytes are limited and have simple options, the printer
>will
>>> never be tied up for long on each transaction and will always be
>able to let
>>> a client know if it is alive and whether there are any problems.
>Then if the
>>> connection fails, it is because the printer is down or the IP
>address is bad.
>>>>Sounds like a fixed SNMP query. Why don't we just use
>>SNMP and the Printer MIB for this kind of thing?
>>>> ...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 --
>>----------------------------------------------------------------------
>>>---------------------------------------------------------------------------
-----
>>>>>>-
>
--=====================_7260730==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font size=3>Notification does not handle the case where a connection or
a 'write' times
out and the client (print server) want to determine if the printer is
currently alive and making progress. The client (print server) needs to
perform a "get printer status" operation immediately and not
wait until some
future notification arrives. The "get printer status" operation
must give a reply
(with a high probability) if the printer is alive.
Bob Herriot
At 01:34 PM 5/14/98 , Harry Lewis wrote:
>Bob stated...
>>>The concern I have about SNMP is that a client's "get
status" query could >be
>behind several GetBulk requests and thus not get processed fast
enough >for the
>client to determine that the printer is alive but very busy.
>>This is one reason notifications are useful rather than
polling.
>>Harry Lewis - IBM Printing Systems
>>>>owner-sdp at pwg.org on 05/14/98 01:43:48 PM
>Please respond to owner-sdp at pwg.org>To: robert.herriot at Eng.Sun.COM, jkm at underscore.com>cc: sdp at pwg.org>Subject: Re: SDP> Suggestions for discussion at SDP session next
week
>>>In my solution, I assume that there is a port dedicated to returning
printer
>status only and it has higher priority for processing than the normal
IPP
>port or the SNMP port. I want to keep the probability of a
reply near 100%
>even when the printer is very busy with other network requests.
>>The concern I have about SNMP is that a client's "get
status" query could be
>behind
>several GetBulk requests and thus not get processed fast enough for
the client
>to
>determine that the printer is alive but very busy.
>>Can an SNMP request have as good a guarantee of a quick response as
a
>dedicated port?
>>Also in my proposal, I assume that the data returned is in an IPP
compatible
>format.
>>Bob Herriot
>>At 08:15 PM 5/13/98 , Jay Martin wrote:
>>Regarding solution "b":
>>>>> b) the primary issue is being able
to determine the printer status, i.e.
>>> did the
connection fail because the printer is down or just busy.
>One
>>> simple
solution is to have a printer read on a UDP port dedicated to
>>> returning a
status summary whenever it receives a request on the
>port. If
>>> the incoming
bytes are limited and have simple options, the printer
>will
>>> never be
tied up for long on each transaction and will always be
>able to let
>>> a client
know if it is alive and whether there are any problems.
>Then if the
>>> connection
fails, it is because the printer is down or the IP
>address is bad.
>>>>Sounds like a fixed SNMP query. Why don't we just use
>>SNMP and the Printer MIB for this kind of thing?
>>>> ...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:
<a href="http://www.underscore.com/" eudora="autourl"><font size=3>http://www.underscore.com</a><font size=3>
--
>>----------------------------------------------------------------------
>>>--------------------------------------------------------------------------------
>>>>>>-
> </font>
</html>
--=====================_7260730==_.ALT--