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@pwg.org on 05/14/98 01:43:48 PM
>Please respond to owner-sdp@pwg.org
>To: robert.herriot@Eng.Sun.COM, jkm@underscore.com
>cc: sdp@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@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"
Notification does not handle the case where a connection or
a 'write' times
--=====================_7260730==_.ALT--
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@pwg.org on 05/14/98 01:43:48 PM
>Please respond to owner-sdp@pwg.org
>To: robert.herriot@Eng.Sun.COM, jkm@underscore.com
>cc: sdp@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@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
--
>>----------------------------------------------------------------------
>>
>--------------------------------------------------------------------------------
>
>
>
>
>
>-
>