My comments are below
Bob Herriot
At 08:54 AM 5/14/98 , 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 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 subroutine
> with 5 as the maximum number of outstanding connections which may
> be queued awaiting acceptance by the server process.
>
> listen(s,5)
Yes, and clients end up timing out when this listen queue is full. But
'listen' is
for TCP, and I am proposing a UDP solution for the printer status so that
there is the least amount of overhead for the printer.
>
> > c) if a write times out, there is no way to know if it because the
> > 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.
Actually, I should have said "there is no way to know if it is because the
printer
is HUNG or just busy". We need a separate query to determine if the printer is
making progress on something.
>
> > d) if a write operation succeeds, there is no way to be 100% sure that
> > the bytes made it to their final destination The success of 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 status,
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 dedicated
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 always be
able to let
> > a client know if it is alive and whether there are any problems.
Then if the
> > connection fails, it is because the printer is down or the IP
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?
My point is that IPP/SDP is and should be transport independent but not
transport absent. We should not define mechanisms in an IPP/SDP layer that
are better handled at a lower transport layer, particularly when those lower
layers already are already defined to do the work for us for transports,
such as TCP/.IP and UDP/IP, and are likely to do so for parallel, USB and 1394.
>
> > c) this is essentially the same problem as b) and has the same
solution.Namely,
> > if a write times out, the client can query status and determine
theproblem.
> > d) I think that we should rely on TCP/IP to get the bytes to their
> > destination. The most likely failure between client and paper is
the
> > network. Loss of data inside the printer seems like such a remote
problem
> > that it isn't worth making the protocol more complicated to solve
this problem.
>
>Again, Transport independent?
Yes I expect any other transport to provide reliability, ordering, etc. It
should not be IPP/SDP
job to do this.
I find it interesting that an old TIPSI requirements document dated 9/94
states the intention of removing transport layer functionality that is still
in TIPSI and that some people still want to add to IPP.
Layering is an important concept. We need to use it for IPP/SDP.
>
> >
> > I hope that we can discuss these ideas via the DL and next week in DC.
> >
> > The solution that I suggest with b) is a new IPP operation over a different
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
>Car
>
--=====================_6657813==_.ALT
Content-Type: text/html; charset="us-ascii"
My comments are below
--=====================_6657813==_.ALT--
Bob Herriot
At 08:54 AM 5/14/98 , 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 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 subroutine
> with 5 as the maximum number of outstanding connections which
may
> be queued awaiting acceptance by the server process.
>
> listen(s,5)
Yes, and clients end up timing out when this listen queue is full.
But 'listen' is
for TCP, and I am proposing a UDP solution for the printer status so that
there is the least amount of overhead for the printer.
>
> > c) if a write times out, there is no
way to know if it because the
> > 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.
Actually, I should have said "there is no way to know if it is
because the printer
is HUNG or just busy". We need a separate query to determine
if the printer is
making progress on something.
>
> > d) if a write operation succeeds, there
is no way to be 100% sure that
> > the bytes
made it to their final destination The success of 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 status, 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 dedicated 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 always be able to let
> > a client know
if it is alive and whether there are any problems. Then if the
> > connection
fails, it is because the printer is down or the IP 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?
My point is that IPP/SDP is and should be transport independent but not
transport absent. We should not define mechanisms in an IPP/SDP layer
that
are better handled at a lower transport layer, particularly when those
lower
layers already are already defined to do the work for us for transports,
such as TCP/.IP and UDP/IP, and are likely to do so for parallel, USB and
1394.
>
> > c) this is essentially the same problem as b)
and has the same solution.Namely,
> > if a write times out,
the client can query status and determine theproblem.
> > d) I think that we should rely on TCP/IP to
get the bytes to their
> > destination.
The most likely failure between client and paper is the
> > network. Loss
of data inside the printer seems like such a remote problem
> > that it isn't worth
making the protocol more complicated to solve this problem.
>
>Again, Transport independent?
Yes I expect any other transport to provide reliability, ordering,
etc. It should not be IPP/SDP
job to do this.
I find it interesting that an old TIPSI requirements document dated 9/94
states the intention of removing transport layer functionality that is
still
in TIPSI and that some people still want to add to IPP.
Layering is an important concept. We need to use it for
IPP/SDP.
>
> >
> > I hope that we can discuss these ideas via the DL and next week
in DC.
> >
> > The solution that I suggest with b) is a new IPP operation over
a different 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
>Car
>