If you have ever set up a computer to print to a remote system, you may have heard of LPR and LPD. If you remember a dialog prompting for a hostname or IP address, followed by a queue name, you have seen it.
Nearly every computer system supports LPR/LPD, as well as networked printers. It's not the only print protocol used today, but it is certainly 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 has similar commands and concepts as LPR. The intent behind 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.
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 LPD essential functions 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, our LPD product, meets and exceeds this statement.
- LPR/LPD is client/server
- LPR is the print client. When you configure LPR, you need to tell it the hostname or IP address of the host running LPD
- LPD is the print server, running on a computer which 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
- 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 you don't happen to have your print job 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 is 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.
RPM goes overboard on detail. We keep several internal logs which you can tune to the level of detail you want. We keep an interactive log, readily available in the user interface.
And we recently introduced "critical events," which appears as a dialog in the user interface. These are conditions we believe we need to let you know.
- LPR/LPD is simple to setup
- 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?" http://web.mit.edu/network/appletalk/lpr.html
- "Difference between LPR and RAW" http://www.differencebetween.net/technology/protocols-formats/difference-between-lpr-and-raw/
Updated by Dave Brooks on Wed 09/08/2020 - 16:34