> 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 subr=
outine
with 5 as the maximum number of outstanding connections which may
be queued awaiting acceptance by the server process.
listen(s,5)
> c) if a write times out, there is no way to know if it because t=
he
> 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.
> 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 =
busy.
One
> 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=
the
port. If
> the incoming bytes are limited and have simple options, the =
printer
will
> 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=
ems.
Then if the
> connection fails, it is because the printer is down or the I=
P
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=
lution.
Namely,
> if a write times out, the client can query status and determi=
ne the
problem.
> d) I think that we should rely on TCP/IP to get the bytes to thei=
r
> destination. The most likely failure between client and pape=
r is the
> network. Loss of data inside the printer seems like such a r=
emote
problem
> that it isn't worth making the protocol more complicated to s=
olve
this problem.
Again, Transport independent?
>
> I hope that we can discuss these ideas via the DL and next week in D=
C.
>
> The solution that I suggest with b) is a new IPP operation over a di=
fferent
route from
> other IPP operations, so the syntax for request and reponse could be=
similar
or different.
> This solution allow IPP for other operations to remain unchanged.
>
> Bob Herriot
>
Carl Kugler
=