Skip to content

queue-model.md

Latest commit

 

History

History
45 lines (32 loc) · 3.83 KB

queue-model.md

File metadata and controls

45 lines (32 loc) · 3.83 KB
Raw

Print queue model

The printer host is authoritative for every RelayPrint job. A client operating-system queue submits IPP operations to a loopback-only bridge. That bridge forwards them to the paired host over pinned TLS, and the host records, authorizes, spools, submits, monitors, and cancels the job. Capability tokens remain encrypted in RelayPrint storage and never appear in the operating-system queue URI.

Each admitted job also stores a validated print ticket containing media name and dimensions, orientation, sides, color mode, quality, and resolution. The ticket survives Create-Job/Send-Document and agent restarts. RelayPrint rejects values that the current host profile or native adapter cannot honor rather than reporting success after silently changing the output. Windows advertises only the physical queue's current color, duplex, and DPI defaults; those raster controls stay driver-owned while RelayPrint applies page size and orientation.

Visibility and privacy

  • The host application can see all jobs targeting printers owned by that host, including the submitting device and document name.
  • A client can retrieve only jobs submitted with its own per-device printer grant.
  • Global queue position is exposed to the job owner so the client can show how many jobs are ahead. Other users' identities and document names are never returned.
  • IPP Get-Jobs, Get-Job-Attributes, Cancel-Job, Close-Job, and the JSON queue endpoint enforce the device identity bound to the printer grant.

Status lifecycle

held → queued → printing → completed, failed, cancelled, or unknown. A job may temporarily enter cancelling; recoverable printer conditions use stopped while the native spooler still owns the job.

  • held means Create-Job succeeded but the document has not arrived.
  • queued means RelayPrint accepted the document.
  • printing means the host operating-system spooler accepted the job and returned a trackable native job ID.
  • stopped means the native spooler reports an actionable condition such as offline, out of paper, a paused queue, or required user intervention.
  • cancelling means RelayPrint accepted a cancellation request and is waiting for the native spooler.
  • completed means the native spooler no longer reports the submitted job. It does not guarantee that paper physically exited the printer.
  • unknown means the native spooler did not produce a terminal state within 10 minutes.

RelayPrint does not automatically resubmit an uncertain job. Automatic resubmission can print duplicate documents after a spooler timeout. The operator should inspect the host printer before submitting the source document again.

Cancellation

  • The host operator may cancel any active job on a locally shared printer.
  • A client may cancel only its own job.
  • When a native job ID exists, cancellation is forwarded to CUPS or the Windows print spooler before RelayPrint records the terminal state.
  • Cancelling a queued upload removes its private spool file.
  • Client cancellation names both the printer ID and job ID so the local agent contacts exactly one host. Host status codes are preserved instead of being collapsed into a generic not-found error.
  • Cancellation is idempotent after a job reaches cancelled. If native cancellation fails, the prior active status is restored with a retryable diagnostic instead of falsely claiming success.

Resource limits

  • Maximum document size: 100 MiB.
  • Maximum spool storage: 512 MiB with serialized quota checks.
  • Maximum active jobs per device per printer: 10.
  • Create-Job reservations expire after two minutes if no document arrives.
  • Recent state responses retain at most 200 local jobs and 100 jobs per remote device queue.

Pairing is the first trust boundary. Every shared printer also uses a per-device capability grant. Blocking a device or stopping printer sharing revokes those grants.