PRODUCT MANUALS

Pocket and Hive manual

PRODUCTS FEATURED

The printer discovery process in a nutshell

The printer discovery activity is actually made up of an elite team of processes. They’re all part of the Edge Node component that leaps into life when you install PaperCut Pocket or Hive.

The processes involved in printer discovery are:

• Scanner process - the tool that hunts down things that look like printers on the network, or locally connected printers on your computer.

• Probe process - once the scanner finds something that looks like a printer, the probe follows behind and sees what kind of printer it is, as well as what it’s capable of (for example, does it have a duplexing unit?).

• Validator process - receives and checks out the information provided by the Probe by further interrogating the printers. Think bright-backlighting and intense questioning.

• Reporter process - sends details about the newly found and verified printer up to the cloud.

• Printer Registry - the ‘printer database in the sky’. This cloud component keeps track of which printers are associated with a specific organization, as well as all the capabilities and properties of the printers.

Scanner - Are there any printers out there?

The scanner’s primary responsibility in printer discovery is to identify sources that look like printers on the device (Windows or macOS queues) - or somewhere on the network. There are two types of scanning:

Local queue scanner

The local queue scanner talks to CUPS (on macOS or Linux) or the Print Spooler (on Windows) to get information about the print queues configured on the local mac or PC. Note that the local queue scanner also moonlights as the ‘probe’ for local queue information. Nifty.

Network scanner

The network scanner starts by picking up clues from local print queues to prioritize which network addresses to scan - and then scans the network for devices that look like printers! The scanner then uses SNMP queries to check that the device found is actually a printer, and if so, what type of printer it is.

Probe - Gather printer details

Luckily nothing too invasive!! The probe uses SNMP and IPP to collect as much data as possible on the printer candidates found by the scanner. The probe isn’t too picky or judgemental about what it finds - all it’s doing is gathering as much information as possible to hand over to the validator.

Validator - Is it definitely a printer?

Just like humans, the printers are yearning for validation - luckily the validator steps up to help validate a printer, before reporting it to the cloud. The validator uses SNMP or IPP requests to further validate the previous findings, and to gather capabilities of the printer - can it do 2-sided prints? Is it out of toner? The validator needs to be able to retrieve at least an IP address, MAC address, and make or model of the printer before it can say ‘yes this is a printer’.

For locally configured queues on the Edge Node, the validator looks for the ConnectionURI (the connection string) in the local queue configuration (e.g. CUPS).

Reporter - Tell the cloud about the printers

After the validator gives the nod to each printer found, the reporter sends the printer candidate (and all the additional SNMP or IPP data found) to the printer registry in the cloud. It’s worth repeating here that everything sent to the cloud - no matter how ‘innocent’ - is encrypted and sent over secure protocols. In this case, HTTPS.

Printer Registry - Making sense of all the printer data

The Printer Registry receives the printer candidate requests from the reporter and begins to piece together a ‘definition’ for each of the printers found. This definition includes the location (including the IP address for network printers or which machine it’s connected to, for a locally attached printer), the make and model of the printer, and its capabilities. From this information, it starts to build a big picture of the printer landscape.

It also creates a co-ordinator map, detailing which Edge Nodes have access to which printers. This is especially important for local printers (for example USB printers) - you can’t print to a USB printer unless you’re sending the job from the machine it’s plugged into! However it’s also important for network printers - organizations may have VLANs and other networking obstacles in place, which means that some printers are only accessible from certain workstations.

If the Print Registry doesn’t have enough information about a printer to build a genuine printer definition, it filters that printer out. It also applies filtering to printers that shouldn’t be registered, like PDF queues (Virtual printers), Fax queues, test printers, PaperCut MF monitored print queues, and PaperCut Mobility Print URIs.

Deduplication / printer matching

Multiple Edge Nodes could report the same printers more than once, so a printer matching algorithm finds matches for already-known printers. Like a dating app of the printer world, it looks at qualities such as IP addresses, ConnectionURIs, MAC addresses, hostnames, and serial numbers - and looks for that perfect match.

Registration

If the Printer Registry doesn’t find a match, (don’t feel too bad for the printer! It means it’s a unique bit of treasure that we’ve found!) then it registers the device as a new printer. It chooses a new name for the device, based on the metadata it received.

Sometimes the registration process will involve updating current printer data - for example, if newly found information is discovered about a printer that is already known. In that case, the device information is updated with the newly found information.

Printer discovery frequently asked questions (FAQs)