| LPRng Reference Manual: 24 Sep 2004 (For LPRng-3.8.28) | ||
|---|---|---|
| Prev | Chapter 19. RFC 1179 - Line Printer Daemon Protocol | Next |
Options used:
longnumber FLAG Long job number (6 digits)
send_data_first FLAG Send data files first
use_shorthostUse short hostname
A job transfer operation starts with a job transfer request, followed by several file transfer operations. At the end of the file transfers, the connection should be closed.
A file transfer request has the form:
| Command | Purpose |
|---|---|
| \001\n | abort |
| \002nnnn cfname | control file transfer |
| \003nnnn dfname | data file transfer |
The abort operation is used to terminate job transfer and indicate that the job should not be processed for printing. The connection will be closed and the partly transferred job will be discarded.
The control file and data file transfer commands have a length (in bytes) of the file and the name of the file to be transferred. When the command is received, the server will reply with a status line:
The reply is only a single octet. Some defective implementations of RFC1179 send a LF after the octet, which makes life very difficult. LPRng makes an effort to detect these non-conforming RFC1179 systems and will accept jobs from them. However, it will not send jobs to them.
If LPRng sends a reject code, as an extension to RFC1179 it also sends an error message. Note that the values for error codes are not defined, nor are their causes. LPRng uses the following values for error codes, which appear to be compatible with many, but not all, of the BSD lpd based systems:
| Code | Error |
|---|---|
| \000 | Accepted, proceed |
| \001 | Queue not accepting jobs |
| \002 | Queue temporarily full, retry later |
| \003 | Bad job format, do not retry |
When the sender gets the reply indicating success, it sends the nnnn bytes of the control or data file, followed by a \000 octet. The receiver will then reply as above; a single \000 octet indicating success.
The above procedure is carried out until all data files and the control file of a job are transferred.
RFC1179 is silent on the following issues:
When sending a job, do you send the control file first, followed by the data file(s), or the data files first?
When sending multiple jobs, can you send them on a single connection, or do you have to establish a new connection for each job?
LPRng will accept jobs whether they are sent control or data files first. By default, it sends the control file first, followed by the data file. If the destination system requires that the data files be sent first, the send_data_first printcap option can be used to force data files to be sent first.
The name of the control file ... should start with ASCII "cfA", followed by a three digit job number, followed by the host name which has constructed the control file.
The should in this wording indicates that this is simply a guideline, and that other formats are possible. Some of the major problems with this format are as follows:
The restriction to 3 digits means that at most 1000 jobs can be in a queue. Strangely, some systems generate far more than 1000 jobs a day, and need to archive them on a regular basis. The longnumber option will allow LPRng to use a 6 digit job number for files in the print queue.
The host name format is not specified. Some implementations consider that this is the short host name, while others think it is the fully qualified domain name (FQDN). LPRng, by default, will use the FQDN host name. However, the use_shorthost option will force it to use short host names in control and data files.
The cfA control file name was modified to allow the job priority to be used as the A letter of the control file. By default, this is A (lowest, i.e. cfA) and but can range to Z (highest, i.e. cfZ). All known spoolers except LPRng seem to ignore the actual value of the letter.