SDP Mail Archive: RE: SDP> Suggestions for discussion at SDP session next week

RE: SDP> Suggestions for discussion at SDP session next week

Jeff Schnitzer (jds@underscore.com)
Fri, 15 May 1998 12:22:41 -0400

Angelo, I tend to agree with you. That is why I mentioned notifications
whic h
(in the context of Bob's particular thread regarding getBulk blocking
GET) was
a subtle way of saying "SNMP trap"... which I don't think of as a new
way to
say "printer down"!

Of course, if you were trying to say... why are we looking at SDP... why
don't
we just use SNMP as the configuration, status and notification
protocol...
sounds good to me too... but that's a more controversial topic, right
now.

Harry Lewis - IBM Printing Systems

Angelo.Caruso@usa.xerox.com on 05/15/98 09:49:57 AM
Please respond to Angelo.Caruso@usa.xerox.com
To: sdp@pwg.org, Harry Lewis/Boulder/IBM@ibmus
cc: robert.herriot@Eng.Sun.COM, jkm@underscore.com
Subject: RE: SDP> Suggestions for discussion at SDP session next week

I believe that in practice this problem would rarely occur. Get Bulk is
appropriate during discovery operations but not generally necessary.
Besides, most implementations are still SNMP v1 and therefore don't use
Get
Bulk anyway. The thought of inventing a brand new mechanism instead of
SNMP
is preposterous. Can't we please stop reinventing the wheel here?

Thanks,
Angelo

-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Thursday, May 14, 1998 4:34 PM
To: sdp@pwg.org
Cc: jkm@underscore.com; robert.herriot@Eng.Sun.COM
Subject: Re: SDP> Suggestions for discussion at SDP session next week

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