[cups.development] [RFE] STR #2732: Status of remote IPP jobs cannot be discovered

[Michael Sweet]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

> If I understand it correctly it means that a
> running backend is needed to get the state
> of a remote IPP job?

Yes

> Does this also mean that the backend must
> keep on running until the remote job is finally
> processed (to notice errors while processing)?

Yes

> How should this work if there are many other jobs
> in the remote queue?

Each client only sends one job at a time to a queue.

> Additionally the backend should exit by default
> as soon as possible to allow maximum throughput.

No!  Doing so means that a user either cannot move a pending job to
another queue or we have to add a lot of complicated and potentially
unreliable caching code with a backend that then has to support cancel
functionality without queuing.

The current implementation prevents a client from hogging a printer for
more than a single job and also supports traditional DNS load balancing
(where a single hostname maps to multiple IPs).

> I think it is not teh backend but only the cupsd
> which should maintain a database of sent IPP jobs
> so that "lpstat -W completed" can show job info.

Adding this to the scheduler might be possible, but at this point I am not
prepared to add that layer of complexity to the scheduler when there will
be little apparent benefit with significant change in behavior.

> Currently "lpstat -W completed" shows only the info
> regarding the local system.

Right, this is by design.

> What is actually missing is something like a "traceroute"
> functionality (i.e. a "tracejob" functionality) which
> queries the remote system about the remote job info.

"lpstat -p" actually does this.

> Therefore cupsd must also keep the remote job IDs and
> the remote host so that it can generate a matching
> query for the remote host.

No.  cupsd shouldn't be doing the remote lookups for the client - that
introduces a lot of performance issues as well as adding complexity to
cupsd.

cupsd is meant as a lightweight server - all long-term operations are
farmed out to helper programs.  This helps to keep cupsd small and simple,
and makes the implementation of the long-term operations simpler as well.

> By default no "tracejob" should be done because it could
> take arbitrary time (think about several subsequent
> remote cupsds which forward the job until it reaches
> its final destination) and arbitraty stuff like network
> timeout could delay the response.

Right, which is why we don't do this in the scheduler - it would be a
recipe for an easy denial-of-service attack. Even helper programs can be
problematic (too many helper apps running...), which is why I say any
"tracing" functionality needs to happen in the client apps (lpstat, lpq)
where any DoS is limited to that program and not the whole printing
system.

Link: http://www.cups.org/str.php?L2732
Version:  -feature