/Jeff
Jeff Schnitzer wrote:
>
> 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 --
> >----------------------------------------------------------------------
> >
> --------------------------------------------------------------------------------