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

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

Carl Kugler (
Thu, 14 May 1998 14:51:58 -0400

Hi Jay,

You wrote:
>Hi Carl,
>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=
>> > currently solve.
>> >
>> > There were four main problems:
>> >
>> > a) no notification
>> > b) if a connection fails, there is no way to know if it becau=
se the
>> > is down or just busy.
>> Socket implementations typically provide for a "backlog".
>> The following program fragment illustrates the use of the listen s=
>> 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.

I don't see what good it does to have an unbounded queue for incoming r=
If requests come in at a rate faster than they can be served, the stora=
requirements and turn-around time will both approach infinity. Is this

For short term bursts, the backlog buffers the connection attemps long =
for the server to respond. In sophisticated printers this response mig=
consist of handing the connection off to a new process or thread and go=
back to the backlog for more connections.

>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 becaus=
e the
>> > printer is down or just busy
>> In many (most?) cases you'll least get a TCP reset when the connecti=
on goes
>> The exceptions would be things like total power failure on the Print=
er, 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.

Okay, but "consciously closed the connection" doesn't necessarily mean =
an application process survived to call "shutdown()" on the connection.=
a process dies, the OS (or runtime environment) can, and normally will,=

reset the connection.

If a backhoe cuts the cable, no protocol can save you.

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

Nothing here you can't do with TCP sockets.

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

If we're going to require TCP/IP, we might as well run IPP 1.0
and SNMP instead of inventing a new SDP.

> ...jay

>-- JK Martin | Email: --=

>-- Underscore, Inc. | Voice: (603) 889-7000 --=

>-- 41C Sagamore Park Road | Fax: (603) 889-2699 --=

>-- Hudson, NH 03051-4915 | Web: --=