IPP Mail Archive: Re: IPP> IPP server needed

Re: IPP> IPP server needed

From: Carl Kugler/Boulder/IBM (kugler@us.ibm.com)
Date: Tue Sep 12 2000 - 11:46:08 EDT

  • Next message: ueda shigeru: "IPP> Questions regarding IPP bake-off"

    Mike Bartman <bartman@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



    This archive was generated by hypermail 2b29 : Tue Sep 12 2000 - 11:55:31 EDT