A couple of comments to your reply to Bob Herriot's recent
posting regarding Microsoft's requirements/concerns for an
SDP-like protocol:
Carl Kugler wrote:
>
> Bob Herriot wrote:
>
> > I talked to Paul Moore yesterday to learn what problems IPP doesn't
> > currently solve.
> >
> > There were four main problems:
> >
> > a) no notification
> > b) if a connection fails, there is no way to know if it because the printer
> > is down or just busy.
>
> Socket implementations typically provide for a "backlog".
> The following program fragment illustrates the use of the listen subroutine
> with 5 as the maximum number of outstanding connections which may
> be queued awaiting acceptance by the server process.
>
> listen(s,5)
This is true, but all too many times folks in the PWG point out
the reality that if you set the queue depth to "n", then there
will likely be situations in which ">n" requests come in. When
the n+1 connection attempt is made, the result (as seen by the
client) is usually the same as a "device not present", i.e.,
no response to the connection attempt.
Use of SNMP and the Printer MIB can alleviate this problem;
it also provides a great degree of scalability.
> > c) if a write times out, there is no way to know if it because the
> > printer is down or just busy
>
> In many (most?) cases you'll least get a TCP reset when the connection goes down.
> The exceptions would be things like total power failure on the Printer, or OS
> kernel hang on the Printer.
As I recall (and someone please correct me here, if necessary),
a TCP Reset is the indication that the other end of the connection
has consciously closed the connection. So, any kind of network
problem can cause serious grief; unfortunately, when it comes to
network problems, the use of alternate IP techniques (such as SNMP)
doesn't usually do much good.
What we do in our driver technology is to put a degree of tolerance
in the write process, whereby the driver accepts a certain period
of write-timeout (so to speak), afterwhich it starts alerting
interested parties in potential problems. After a configured
period has been reached in which no writing has been possible,
the driver considers the situation to be terminal, and attempts
to restart the print job from the beginning.
It would be interesting to hear how others handle this situation.
> But isn't this one of the SDP requirements:
>
> 7. The SDP protocol must be completely Transport independent.
>
> and wouldn't this solution be dependent on UDP and IP?
Yeah, you're right. Use of SNMP in transport environments
that don't currently support SNMP will require the use
of some other similar technique. This is the reason we
added SNMP OID access into TIP/SI, thereby making it work
quite well in serial/parallel applications.
...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 --
----------------------------------------------------------------------