You are here: How it works

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

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.

  • UDP multicast
  • Source port 5353

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.

  • Source port 53

Find out more about DNS.

HTTP(S) API 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).
  • Source port 53 or 5353
  • TCP Port 9163 and 9164

More 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.

To learn even more, take a look at mDNS.

More 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.

DNS communication diagram clients connect to DNS server and DNS server relays the record from Mobility Print server

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 job delivery

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.

  1. Tom’s phone discovers printers using DNS (DNS-SD) or mDNS.

  2. 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).

  3. 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)
  4. 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).

  5. The job is placed in the operating system’s print queue (for example, the Windows print queue).

  6. The job is delivered to the physical printer.

An example workflow on Windows

Tom wants to print a document from his laptop.

  1. Tom clicks Print and selects a printer. A standard set of print options are offered (duplex, color, copies).
  2. The print job arrives at the Mobility Print Server as a PostScript file generated by PaperCut Software’s Global Printer Driver.
  3. 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.

Protocols and ports

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

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:

  1. At the time of installation of the print queue, the Application Server validates the username and password.
  2. If valid, the Application Server returns an IPP URL with an encoded access token to the client.
  3. A standard Windows IPP printer is automatically created using this special URL.
  4. The client uses this URL to deliver print jobs via IPP.
  5. Every time there is a print job, the Mobility Print server validates the access token.

Ghost Trap

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).