IPP> IPP server needed

IPP> IPP server needed

IPP> IPP server needed

Carl Kugler/Boulder/IBM kugler at us.ibm.com
Tue Sep 12 11:46:08 EDT 2000


Mike Bartman <bartman at p...> wrote:
...
>
> One other comment.  I didn't note anything in the IPP 1.0 RFCs that
> specified things like link timeouts.  I'm currently fighting a problem
> involving a printer that times out and drops the link within a couple of
> seconds of opening it if there's no traffic.  This may make it impossible
to
> use this printer from anything other than a dedicated computer, as timing
on
> a multi-user system is not predictable and things like queue printing
tend
> to get low CPU priorities.  I know that link level things are not really
a
> part of a protocol like IPP, but it might be useful to have some "hints
and
> suggestions" somewhere to cue server implementers into such potential
> problems.

The IPP Implementer's Guide does have some discussion about this in section
7 Encoding and Transport:

<< IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to
throttle clients when Printers are busy.  Therefore, it is perfectly normal
for an IPP client transmitting a Job to be blocked for a really long time.
Accordingly, socket timeouts must be avoided.  Some socket implementations
have a timeout option, which specifies how long a write operation on a
socket can be blocked before it times out and the blocking ends.  A client
should set this option for infinite timeout when transmitting Job
submissions.

Some IPP client applications might be able to perform other useful work
while a Job transmission is blocked.  For example, the client may have
other jobs that it could transmit to other Printers simultaneously.  A
client may have a GUI, which must remain responsive to the user while the
Job transmission is blocked.  These clients should be designed to spawn a
thread to handle the Job transmission at its own pace, leaving the main
application free to do other work.  Alternatively, single-threaded
applications could use non-blocking I/O.

Some Printer conditions, such as jam or lack of paper, could cause a client
to be blocked indefinitely.  Clients may open additional connections to the
Printer to Get-Printer-Attributes, determine the state of the device, alert
a user if the printer is stopped, and let a user decide whether to abort
the job transmission or not.  >>

Of course, it's legal for either side to drop the connection at almost any
time.  But this sounds like a poor implementation to me.  I don't know what
they think they're saving by dropping the connection after a few seconds.
If you're forced to reconnect more often than once every four minutes, the
Printer will use more memory for connections in TIME_WAIT than it would for
a connection held open.

I agree that many of the available printer implementations are broken in
one way or another.  Just try to find one that correctly handles the
subtleties of Get-*-Attributes with "requested-attributes" specified!

     -Carl

> Just a suggestion based on real world experience with an IPP 1.0 (sort
of)
> printer.
>
> -- Mike Bartman
>    Process Software
>    Principle Software Engineer




More information about the Ipp mailing list