Supported Protocols
RPM accepts print jobs through several different interfaces, and every one of them lands in the same place: a named queue, processed according to whatever transforms and actions you’ve configured for it. Whichever protocol your environment already speaks, RPM speaks it too.
LPR/LPD
LPR/LPD is documented in RFC 1179 — a standard that’s less intuitive than its wide adoption might suggest. Client implementations vary a lot in practice; many mainframe print clients, and Microsoft’s own LPR client, follow the spec only “nearly correctly.” RPM’s LPD handler is built with that reality in mind: it includes extensive logging, plus an optional capture file that records exactly what a client sends, without exposing the actual print data — the protocol handshake, not the document contents, is usually where compatibility problems hide.
The queue name travels as part of the LPD exchange itself, which means RPM can create new queues automatically as jobs arrive under names it hasn’t seen before. That’s genuinely useful when standing up a new RPM instance — point a client at it and watch queues appear, then decide how to configure each one afterward. It’s worth turning off once initial setup is done, though, since security scanners tend to generate a lot of random queue-name traffic that you don’t want cluttering a production instance.
LPD also carries useful metadata alongside the job itself: the job name, filename, an optional title, the sending host’s self-reported name, the queue name, and occasionally formatting directives like page width and height. Beyond “print this file,” LPD supports status queries (both long and short form) and a “start printer” command, which RPM accepts without requiring it.
There is quite a bit more worth knowing about LPR/LPD which you can find on our What is LPR/LPD page and the Advanced Topics page.
Telnet
We added Telnet support at the request of a customer running a major airline reservation system, where print jobs arrived on a single TCP connection and were meant to print the moment the client closed that connection — simpler, in some ways, than LPD.
Before long, customers asked for “quiet print” as well: if no data arrives within a configured window, that silence itself signals the job is complete, and RPM keeps listening on the same connection for whatever comes next. Telnet itself is described in RFC 854 and RFC 855, covering conventions for text delimiters like carriage return, line feed, and form feed.
Each Telnet handler you configure listens on a specific port and directs jobs to a specific queue — the same queue model LPD uses — and RPM has no trouble running multiple Telnet handlers side by side.
For much more on how RPM supports the telnet/port 9100/raw print protocol please see How Telnet Printing Works in RPM
AppSocket
AppSocket is the common name for HP’s JetDirect protocol. It’s not an official Internet standard — no RFC exists for it — but it’s supported by a wide range of printer manufacturers regardless.
AppSocket traffic breaks down into two kinds of commands:
- PJL (Print Job Language) — describes the job and the communication itself: declaring the job name and printer language, setting parameters like timeout period, handling queries RPM responds to immediately, and status commands.
- PCL (Printer Control Language) — the actual content: text, images, fonts, everything that ends up on the page.
One PJL status feature worth knowing about: a print client can ask RPM to report status whenever the printer ejects a page. Since RPM never begins printing until a job has fully arrived, it can’t observe page-ejection in real time the way a physical printer does — where possible, RPM does its best to respond appropriately, but this is one place where AppSocket’s design assumes a live physical device more directly than RPM’s architecture does. Clients can still query RPM the same way they’d query a printer, and RPM answers with the appropriate job data or settings.
As with Telnet, each AppSocket handler is configured to listen on a specific port and feed a specific queue.
There’s a good deal more to AppSocket than fits here — configuration, the PJL command and status listings, printer emulation and timeouts. Start at AppSocket support for PJL; every article in the set is linked from the sidebar there.
Folder Watcher
RPM can associate a folder on your PC directly with a queue — often called a “hot folder.” (Shared network folders aren’t supported as a source; this needs to be a local folder.)
For every file RPM detects in the watched folder, it checks whether the file is still open, confirms the file size has stopped growing, and only once the file is genuinely closed does it submit the job — moving the data into that queue’s spool folder and posting the metadata the same way any other protocol would. It doesn’t matter what actually created the file; a command-line copy, a program generating output, anything that follows the normal create-write-close file sequence works the same way. You can literally watch this happen in File Explorer: files appear in the watched folder, and after a few seconds, disappear — that’s RPM moving them into its own spool structure.
Folder watching is covered in depth across its own set of articles — installation, configuration, licensing, compatibility and more. Start at Understanding Queue Folders; the rest are linked from the sidebar there.
RPC/JSON
RPM reserves a dedicated port for communication with its own user interface, built around two categories of traffic: the UI telling RPM about configuration changes, and RPM telling the UI about job status as jobs are created and processed. The whole exchange is plain JSON, sent both directions — and while we built it for our own UI, it’s general enough that other programs can use it too; some of our custom client work has done exactly that, including a small Python script we use to submit files in a folder directly to a specific queue.
One real advantage of the RPC path specifically: when a job comes in this way, RPM completes the entire job-creation process directly, without the spooling steps every other protocol requires.