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