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’ devices.
Mobility Print’s goal is to simplify printing so it just-works on any client (such as iPhone, Chromebook, Android phone), and provide a consistent print experience irrespective of the make and model of printer. It achieves this by having the server do the heavy lifting. At a high level it helps with the following:
- Printer discovery — helps end users find printers on the client
- Print job delivery — deliver 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 it supports.
This discovery is done using one of three methods depending on the selected setup and the client 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, 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). It is 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 job delivery
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 (e.g. 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 (e.g. 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 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! Here is an example of the flow on Apple iOS, Chrome, or 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 then selects a printer.
A standard set of print options are offered (duplex, color, copies).
- Tom selects the options (e.g. 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
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 (e.g. the Windows print queue).
The job is delivered to the physical printer.
Did I hear you say you’d like to dive deeper? Sure. Let’s add a Windows laptop to the mix! For Windows there are a few extra steps between 5 and 6:
The job is not yet PDF. From Windows, it arrives as PostScript generated by PaperCut Software’s Global Driver.
The PostScript is converted to PDF using GhostTrap (installed by default).
Having this information is great when diagnosing why a print job doesn’t print.
Protocols and ports
|Client||Client Software?||Discovery Protocols||Port (source)||Delivery Protocols||Port (server)|
|Android||Mobility Print app||DNS and HTTPS or
mDNS and HTTPS
|53 and 9164
5353 and 9164
|Chrome||Mobility Print app||DNS and HTTP or
mDNS and HTTP
|53 and 9163
5353 and 9163
|Windows||Installer||DNS and HTTPS or
mDNS and HTTPS
|53 and 9164
5353 and 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 the PaperCut Application Server, which usually validate via the server’s operating system (e.g. via Active Directory, or LDAP). User security (e.g. group based access control) are 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:
Click here to download.
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 distribution’s documentation for further details. You should ensure that the gs command is on the PATH (for the papercut user).