If you have set up a computer to print to a remote system, you may have heard of LPR and LPD.
When you set up using a remote hostname and queue name, you're working with LPR. LPR is the "line print requestor" or, in plain English, "please print this file at this location."
LPD is the "line print daemon" which is a way of saying it handles incoming print requests from LPR.
Nearly every computer system supports LPR/LPD and networked printers. Of course, it's not the only print protocol used today, but it is undoubtedly well-represented.
LPR/LPD comes from the Berkeley print system, part of the BSD or Berkeley Software Distribution. BSD, in turn, follows UNIX System V, one of the first commercial versions of Unix System V printing with similar commands and concepts to LPR. LPR/LPD was to be more uniform across different Unix systems.
Windows platforms, by default, support LPR/LPD printing. You may have to enable a setting to make LPR available to you.
The Internet Engineering Task Force (or IETF) sponsors documents that define network protocols and practices of many types. Among these documents are the RFCs, or "Request for Comments." RFC 1179, published in August 1990, defines LPR/LPD.
This chart shows terms frequently used with LPR/LPD, matched with what I believe to be the correct perspective. I've included hyperlinks to take you to the explanation in this article.
|The act of sending a job using LPR||
LPR is the "Line Printer Remote" protocol. It works with LPD, which is the "Line Printer Daemon." LPR and LPD work together like "send" and "receive" or "command" and "execute."
The "remote" part of LPR refers to sending a file to a printer or print server "somewhere," including the same office, building, or a different continent. The way LPR works over the network, printing locally works the same as printing anywhere on earth (if your network connection is good).
LPR is very similar to uploading a file or sending a mail message, except that it's a print job. LPR includes three primary functions for sending print jobs:
- specify a named queue
- send data about the print job
- send the print job
Wikipedia adds the following advantages of LPR:
- with LPR, you can migrate your print processes to a single print protocol
- platform independence
- and it's accessible via the Internet
LPD is the listener, and LPR sends requests to LPD. They speak the same language. That is the intent of the graphic at the top of the page.
The essential functions of LPD include:
- waiting for LPR to send a job or other-print related command
- handling multiple queues and multiple printers
- matching a queue name with the proper job processing
Wikipedia points out that commercial applications of LPR and LPD offer more robust functionality and performance. We believe RPM Remote Print Manager® ("RPM"), our LPD product, meets and exceeds this statement:
- we handle as many concurrent incoming connections as Windows will support
- unlimited named queues, each with a separate configuration
- very wide variety of data processing options and outputs
- extensive logging and error reporting
- LPR/LPD is client/server
- LPR is the print client. When you configure LPR, you tell it the hostname or IP address of the host running LPD
- LPD is the print server, running on a computer that is accessible to LPR
- LPR/LPD uses port 515
- nearly any networking computer reserves port 515 for print requests, even if it does not have an LPD present
- sources refer to port 515 as the "LPR port" or the "LPD port" because LPR talks TO the port, and LPD listens ON the port
- Any print request includes:
- destination hostname or IP address, that is, where the LPD is running
- a TCP/IP port (nearly always 515)
- the name of the print queue you're sending the jobs to
- metadata which describes the job, including the job name, optionally the number of copies, and more
- and, naturally, the print data
I have reviewed the vendor specifications for numerous printers and hardware print servers. Nearly all of them supported LPD, with one or more pre-configured queues. Typically, one queue handles plain text while another supports pre-formatted print jobs in the printer's native language.
Many hardware print servers have no internal queue names, or they will have one such as "LPT1". They merely route all incoming jobs directly to the printer. If your print job is not in the correct format, you may lose the job with no reporting.
I believe that most, if not all, of the software print servers I've reviewed, allow you to add queue names and may specify one or more processing settings.
RPM lets you create essentially unlimited queues. I have seen one customer configuration with between 800 and 900 queues. The program startup took a little longer, but the job processing speed was not affected.
How RPM improves on error reporting
In the sources I reviewed for this article, one of the chief complaints about LPR/LPD is that you don't get much detail if there is an error.
On the other hand, RPM goes overboard regarding detail. We keep several internal logs that you can tune to the level of detail you want:
- a diagnostic log for each module in the project, which you can turn on or off by module
- a message log that covers the primary activities, such as receiving and printing, with varying degrees of detail
- an event log for one-time or exception events
- a critical events log that displays in the user interface for situations we deem worthy of immediate attention
- LPR/LPD is simple to set up
- LPR/LPD is very platform-independent; the LPR does not know what kind of host or printer the LPD is running on, and vice versa
- With a mature commercial product, you'll have many options not available in the lower end
- "Line Printer Daemon protocol" https://en.wikipedia.org/wiki/Line_Printer_Daemon_protocol
- "List of printing protocols" https://en.wikipedia.org/wiki/List_of_printing_protocols
- "What is LPRL?" https://web.mit.edu/network/appletalk/lpr.html
- "Difference between LPR and RAW" http://www.differencebetween.net/technology/protocols-formats/differenc…
Updated by Dave Brooks on Wed 12/21/2022