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=
't
>> > 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
printer
>> > is down or just busy.
>>
>> Socket implementations typically provide for a "backlog".
>> The following program fragment illustrates the use of the listen s=
ubroutine
>> 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=
equests.
If requests come in at a rate faster than they can be served, the stora=
ge
requirements and turn-around time will both approach infinity. Is this
desirable?
For short term bursts, the backlog buffers the connection attemps long =
enough
for the server to respond. In sophisticated printers this response mig=
ht
consist of handing the connection off to a new process or thread and go=
ing
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
down.
>> 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 =
that
an application process survived to call "shutdown()" on the connection.=
If
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: 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 --=
>----------------------------------------------------------------------=
>
-Carl
=