How it works
This section is quite technical! It’s intended for system administrators who like to see what’s under the hood! Knowing a system’s architecture and design can help you support the system, or at least scratch the curiosity itch.
Mobility Print sits locally on your network and publishes printers to your end users’ clients. Mobility Print’s goals are to simplify printing so it 'just works' on any client (such as an iPhone, Chromebook, or Android phone), and to provide a consistent print experience irrespective of the make and model of printer. And it achieves this by having the server do the heavy lifting.
At a high level, Mobility Print helps with the following:
- Printer discovery — lets end users use their client to find printers
- Print job delivery — delivers a print job from a client to a printer. The print job delivery method is dependent on the type of client being used.
Mobility Print sits on the print server in front of the existing print services. It provides a new set of services (protocols) to achieve a streamlined print experience. The existing native print queuing system and drivers installed on the system are still used and not bypassed. You get the benefit of both worlds!
Let’s dive into detail about these methods:
Mobility Print clients need to discover printers, that is, discover each printer’s name and IP address, as well as the features they support.
This discovery is done using one of three methods depending on the selected setup and the client's operating system.
mDNS is an open standard
and uses UDP broadcasting. It is ideal for smaller networks that don’t rely on a local DNS
server. Shared printer information is broadcast and encoded into the mDNS packets.
DNS discovery uses an existing DNS infrastructure to transmit printer information. The information
is broadcast and encoded with the DNS-SD standard.
Some clients, such as Android and Chrome clients, use a simplified HTTP(S)-based protocol to
receive printer information. First the Mobility Print server host is discovered using
either DNS or mDNS, then printer information is fetched using HTTP(S).
To find out more about mDNS and DNS Service Discovery (DNS-SD), check out these useful resources:
What you should know about mDNS
mDNS is a local subnet protocol. By default, broadcasting occurs across only one subnet. Although it is possible to extend mDNS across subnets using mDNS “reflectors” or “bonjour gateways” and other methods, most multi-subnet sites should use DNS discovery. mDNS discovery is best for organizations:
- with one subnet, or one subnet per location
- where a local DNS server does not exist
- that do not filter out multicast UDP traffic
- with networks that have low packet loss.
What you should know about DNS
The Mobility Print server has a mini embedded DNS server. You need to configure your local DNS server to forward printer discovery requests to the Mobility Print server’s embedded DNS.
Forwarding is achieved using a method called “subzones” or “delegated subzones”. This is an elegant solution because when you add or remove new printers, no local DNS configuration is required. It’s all automatic and delegated to the Mobility Print server. DNS discovery is best for organizations:
- with multiple subnets per location
- where a local DNS server exists
- that filter out UDP multicast traffic
- with networks that have high packet loss.
What’s under the hood? Mobility Print’s DNS and mDNS implementations are embedded (run in-process). They are written in the Go programming language. Working at the raw UDP multicast level has made for tough programming, however, the approach has given us the control we require to provide the best experience. We’ve been able to tweak caching behavior, name formatting, and support the widest range of devices. Oh, and let’s not forget it’s made for many long chats around the coffee machine.
Print jobs are normally transferred from the client in PDF format using IPP (Internet Printing Protocol). PDF is a fantastic interchange format as it’s printer vendor independent. The Mobility Print server then converts the PDF file into the printer’s own PDL (for example, PostScript or PCL) ready for printing. This means the clients don’t need to have a vendor/brand specific print driver. The server does the conversion taking the complexity away from the client and the end-user.
Each client’s operating system has it’s own print infrastructure and user interface. For some clients it is built in (for example, iOS), while for others it requires additional software. Where additional device software is required, Mobility Print aims to provide:
- the simplest end-user print experience
- the same experience irrespective of the brand of printer
- leverage of the client’s standard print interface (no new “apps” to learn how to use)
What’s under the hood? Internet Printing Protocol (IPP) has rapidly become the defacto standard for print job transfer. It’s used by CUPS on Linux, Mac, and internally supported by the majority of printers. IPP everywhere! Mobility Print has it’s own IPP embedded stack. It’s a modern stack written by the team in-house in the Go language. We’re all experts on print protocols here at PaperCut Software, however reading through all 1000+ pages of RFC documents has been no mean feat! We’re very proud of our implementation and plan on using it as a foundation for future features and products.
To understand the system, it’s important to know the print system workflow. Bear with us, we’ll get quite deep!
An example workflow on Apple iOS, Chrome, and Android
Tom is an end user who selects the Print button on his phone.
Tom’s phone discovers printers using DNS (DNS-SD) or mDNS.
Tom selects the options (for example, duplex) then taps Print. The job’s content is delivered to the Mobility Print server as a PDF file over the IPP protocol (iOS) or HTTP API (Chrome and Android).
The PDF and the selected job attributes are spooled into
data/spool. Three files are generated for each job:
- job content in PDF (*.pdf)
- print job options/instructions (*.ticket.toml)
- printing state for the job (*.info.toml)
The Mobility Print server converts the PDF to the required Page Description Language (PDL) used by the printer, such as PostScript or PCL, using the drivers installed on the server (avoiding the need for vendor drivers on the client).
The job is placed in the operating system’s print queue (for example, the Windows print queue).
The job is delivered to the physical printer.
An example workflow on Windows
Tom wants to print a document from his laptop.
- Tom clicks Print and selects a printer. A standard set of print options are offered (duplex, color, copies).
- The print job arrives at the Mobility Print Server as a PostScript file generated by PaperCut Software’s Global Printer Driver.
- If the destination printer uses:
- the PaperCut Global Printer Diver, there is no conversion to PDF and the job is printed
- a native driver, Mobility Print Server converts the PostScript file to PDF using GhostTrap (installed by default) and prints the job.
Understanding the different workflows from a phone and laptop is really important when diagnosing why a print job doesn’t print.
|Client||Client Software?||Discovery Protocols||Port (source)||Delivery Protocols||Port (server)|
|macOS||No||DNS or mDNS||53 5353||IPPS/HTTPS||9164|
|iOS||No||DNS or mDNS||53 5353||IPPS/HTTPS||9164|
|Android||Mobility Print app||DNS and HTTPS or mDNS and HTTPS||53 and 9164 5353 and 9164||HTTPS API||9164|
|Chrome||Mobility Print app||DNS and HTTP or mDNS and HTTP||53 and 9163 5353 and 9163||HTTP API||9163|
|Windows||Installer||DNS and HTTPS or mDNS and HTTPS||53 and 9164 5353 and 9164||IPP/HTTPS||9164|
User authentication is used to identify users and associate their identity with the print job. Jobs will appear in the server’s print queue with this user identity. Usernames and passwords are validated by the PaperCut Application Server, which usually validates via the server’s operating system (for example, via Active Directory, or LDAP). User security (for example, group based access control) is also enforced using this identity.
On all devices except Windows laptops, username and password validation is performed in real-time prior to receiving a print job. For Windows, a different process is used:
- At the time of installation, the server validates the username and password.
- If valid, the server returns an IPP URL with an encoded access token.
- A standard Windows IPP printer is created using this special URL.
- The client uses this URL to deliver print jobs via IPP.
- The Mobility Print server validates the access token for each print job.
Ghost Trap is a security hardened version of Ghostscript. It's open source software supported by PaperCut Software. It brings best-of-breed security to the popular PostScript and PDF conversion software by utilizing the same sandbox security technology used by the Google Chrome Browser. You can read more about this project here:The Ghost Trap Project Page.
Ghost Trap is required to be installed on the Mobility Print Server if you’re supporting Windows devices because we do a PostScript to PDF conversion. See the Print job delivery section above for more details. Below are the links to download and install Ghost Trap on your Mobility Print Server:
Windows Server: Click here to download.
Mac Server: Install the PostScript viewing software Ghostscript version 9.06. Richard Koch from the University of Oregon maintains a Mac version of Ghostscript. Download this here. NOTE: If you're using the Homebrew package manager, there is a ghostscript package available for install.
Linux and Novell OES servers: All major Linux distributions either come with Ghostscript automatically installed, or an option to install via the standard package manager. See your distributor's documentation for further details. You should ensure that the gs command is on the PATH (for the Papercut user).