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 11:54:28 -0400

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 =
> is down or just busy.

Socket implementations typically provide for a "backlog".
The following program fragment illustrates the use of the listen subr=
with 5 as the maximum number of outstanding connections which may
be queued awaiting acceptance by the server process.


> c) if a write times out, there is no way to know if it because t=
> printer is down or just busy

In many (most?) cases you'll least get a TCP reset when the connection =
The exceptions would be things like total power failure on the Printer,=
or OS
kernel hang on the Printer.

> d) if a write operation succeeds, there is no way to be 100% sur=
e that
> the bytes made it to their final destination The success o=
f a
write only
> means that the TCP/IP layer succeeded.
> The solutions:
> a) notification: the IPP group is close to a solution
> b) the primary issue is being able to determine the printer stat=
us, i.e.
> did the connection fail because the printer is down or just =
> simple solution is to have a printer read on a UDP port dedi=
cated to
> returning a status summary whenever it receives a request on=
port. If
> the incoming bytes are limited and have simple options, the =
> never be tied up for long on each transaction and will alway=
s be
able to let
> a client know if it is alive and whether there are any probl=
Then if the
> connection fails, it is because the printer is down or the I=
address is bad.

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?

> c) this is essentially the same problem as b) and has the same so=
> if a write times out, the client can query status and determi=
ne the
> d) I think that we should rely on TCP/IP to get the bytes to thei=
> destination. The most likely failure between client and pape=
r is the
> network. Loss of data inside the printer seems like such a r=
> that it isn't worth making the protocol more complicated to s=
this problem.

Again, Transport independent?

> I hope that we can discuss these ideas via the DL and next week in D=
> The solution that I suggest with b) is a new IPP operation over a di=
route from
> other IPP operations, so the syntax for request and reponse could be=
or different.
> This solution allow IPP for other operations to remain unchanged.
> Bob Herriot

Carl Kugler