The main advantage of using LPD protocol is that it is widely supported. However, there are several disadvantages. LPD protocol does not support checkpoint/restart because confirmations can only be requested at the end of the print data file. In addition, the confirmation indicates only that the print file has been received at the remote host. The print file may or may not have been printed. It can be difficult to determine the reason for an error when using LPD protocol, since there are no defined negative responses.
Another disadvantage of using LPD protocol is that there is no way to query a TCP/IP printer to obtain any configuration or status information, because the LPD protocol is intended to support communication with a print server that would spool the data; the LPD protocol does not describe any direct communication with the printer itself.
DIRECT TCP/IP CONNECTION
Some printers support a direct TCP/IP connection, which provides a “socket-to-socket” connection for a client program to send print files to a printer. This connection is often referred to as “sockets” protocol, and it allows for twoway communication directly with the printer, instead of communication with a print server. The printer has a specific port that is used to listen for a direct TCP/IP connection; for many devices, this port is 9100.
The sender can verify that a print file has been received and that it has been printed successfully by sending commands to the printer and obtaining responses. Because these commands can be used to verify when each page has been printed, this type of connection can support checkpoint/restart. A direct connection can also provide information about the status of the printer, including a condition that requires operator intervention, such as an “out of paper” state. One type of printer-specific command that can be used to communicate with a printer using a direct TCP/IP connection is Printer Job Language (PJL). PJL was developed by Hewlett-Packard (HP) and is supported by most HP-compatible laser printers.
Figure 2 shows an example of a direct TCP/IP connection using PJL commands to communicate with the printer. The print server sends PJL INFO commands to obtain information about the printer, including what printer languages it supports (e.g., PCL or PostScript), whether it supports duplex, etc. Then, the print server sends PJL USTATUS commands to indicate that the sender wants to receive unsolicited status responses when the device status changes, when each page is printed, when the job is complete, and on timed intervals. The server sends a PJL JOB command to indicate the beginning of the print file, followed by the buffers of the print file, and the PJL EOJ command to indicate the end of the print file. The printer responds to the JOB START and then sends a USTATUS PAGE response as each page is printed. When the last page is printed, the printer sends the USTATUS JOB END response with a total page count.
If there are any changes in the device status while the job is printing, the printer will report the status to the print server. For example, the printer will report states that may require intervention, including empty paper trays or a paper jam. When the printer is returned to ready state, it will report the new status and continue printing. If a printer error occurs that does not allow continuation, the print server can remember which pages have printed successfully and resume printing at the next sequential page when the print job is restarted. In the example in Figure 3, the printer responds to the JOB START and then sends a USTATUS PAGE response as each page is printed. When the printer runs out of paper after page 1, the printer sends an abnormal status condition (CODE=41202) to the print server, and the abnormal status code is displayed for the operator. When paper is placed in the proper tray, the printer sends a normal status code (CODE=10001), and the server continues printing. When the last page is printed, the printer sends the USTATUS JOB END response with a total page count.
The most important advantage to using a direct TCP/IP connection is that the print server can ensure that each file has been successfully printed. In addition, the print server can report normal or abnormal printer status to operators; for example, the “empty paper tray” status can be displayed to notify an operator to put paper in the printer. A direct TCP/IP connection also allows the print server to obtain details about the printer configuration. If the print server determines that a file is queued to a printer in a printer language (e.g., PCL or PostScript) that is not supported by the printer, an error can be reported and the file can be held or redirected to a printer that supports the requested language.