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’s goals are simple: make printing so it 'just works' on any client (such as an iPhone, Chromebook, or Android phone), and provide a consistent print experience irrespective of the make and model of the printer. And it achieves both by having the Mobility Print server do the heavy lifting.
In a nutshell, Mobility Print sits locally on your network and publishes printers to your end users’ clients. It 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 method use to deliver 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!
Now let’s dive into detail:
- Printer discovery
- Print job delivery
- What else you should know...
- Protocols and ports
- User authentication
Clients can print only after they've discovered the available printer names, IP addresses, and supported features. The way they discover these details depends on the way the environment is set up and the client's operating system.
Ideal for smaller networks that don’t rely on a local DNS server.
mDNS is an open standard and uses UDP broadcasting. Shared printer information is broadcast and encoded into the mDNS packets.
Find out more about mDNS.
Ideal for networks with one or more servers and subnets.
DNS discovery uses an existing DNS infrastructure to transmit printer information. The information is broadcast and encoded with the DNS-SD standard.
Find out more about DNS.
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).
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.
To learn even more, take a look at mDNS.
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.
To learn even more, take a look at DNS-SD
Print jobs are normally transferred from the client to the Mobility Print server 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's built in (for example, iOS), while for others (for example, Android) it requires users to download an app.
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 identifies users and associates their identity with the print job. Jobs appear in the server’s print queue with this user identity.
Usernames and passwords are usually validated by the Application Server its 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, the Application Server validates the username and password in real-time prior to receiving a print job.
For Windows, the authentication process is:
- At the time of installation of the print queue, the Application Server validates the username and password.
- If valid, the Application Server returns an IPP URL with an encoded access token to the client.
- A standard Windows IPP printer is automatically created using this special URL.
- The client uses this URL to deliver print jobs via IPP.
- Every time there is a print job, the Mobility Print server validates the access token.
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: 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).