> 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,=
kernel hang on the Printer.
> d) if a write operation succeeds, there is no way to be 100% sur=
> the bytes made it to their final destination The success o=
> 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=
> did the connection fail because the printer is down or just =
> simple solution is to have a printer read on a UDP port dedi=
> returning a status summary whenever it receives a request on=
> the incoming bytes are limited and have simple options, the =
> never be tied up for long on each transaction and will alway=
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=
> 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=
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=
> other IPP operations, so the syntax for request and reponse could be=
> This solution allow IPP for other operations to remain unchanged.
> Bob Herriot