Network Printing Working Group                L. McLaughlin III, Editor Request for Comments:  1179                        The Wollongong Group                                                              August 1990                      Line Printer Daemon Protocol
Status of this Memo
This RFC describes an existing print server protocol widely used on
the Internet for communicating between line printer daemons (both
clients and servers).  This memo is for informational purposes only,  and does not specify an Internet standard.  Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol.  Distribution of
this memo is unlimited.
1. Introduction
The Berkeley versions of the Unix(tm) operating system provide line
printer spooling with a collection of programs: lpr (assign to
queue), lpq (display the queue), lprm (remove from queue), and lpc
(control the queue).  These programs interact with an autonomous
process called the line printer daemon.  This RFC describes the
protocols with which a line printer daemon client may control
printing.
This memo is based almost entirely on the work of Robert Knight at
Princeton University.  I gratefully acknowledge his efforts in
deciphering the UNIX lpr protocol and producing earlier versions of
this document.
2. Model of Printing Environment
A group of hosts request services from a line printer daemon process    running on a host.  The services provided by the process are related    to printing jobs.  A printing job produces output from one file.
Each job will have a unique job number which is between 0 and 999,
inclusive.  The jobs are requested by users which have names.  These    user names may not start with a digit.
3. Specification of the Protocol
The specification includes file formats for the control and data
files as well as messages used by the protocol.
McLaughlin                                                      [Page 1]
3.1 Message formats
LPR is a a TCP-based protocol.  The port on which a line printer
daemon listens is 515.  The source port must be in the range 721 to
731, inclusive.  A line printer daemon responds to commands send to
its port.  All commands begin with a single octet code, which is a
binary number which represents the requested function.  The code is
immediately followed by the ASCII name of the printer queue name on
which the function is to be performed.  If there are other operands
to the command, they are separated from the printer queue name with
white space (ASCII space, horizontal tab, vertical tab, and form
feed).  The end of the command is indicated with an ASCII line feed
character.
4. Diagram Conventions
The diagrams in the rest of this RFC use these conventions.  These
diagrams show the format of an octet stream sent to the server.  The    outermost box represents this stream.  Each box within the outermost    one shows one portion of the stream.  If the contents of the box is
two decimal digits, this indicates that the binary 8 bit value is to    be used.  If the contents is two uppercase letters, this indicates
that the corresponding ASCII control character is to be used.  An
exception to this is that the character SP can be interpreted as
white space.  (See the preceding section for a definition.)  If the
contents is a single letter, the ASCII code for this letter must be
sent.  Otherwise, the contents are intended to be mnemonic of the
contents of the field which is a sequence of octets.
5. Daemon commands
The verbs in the command names should be interpreted as statements
made to the daemon.  Thus, the command "Print any waiting jobs" is an    imperative to the line printer daemon to which it is sent.  A new
connection must be made for each command to be given to the daemon. 5.1 01 - Print any waiting jobs
+----+-------+----+
| 01 | Queue | LF |
+----+-------+----+
Command code - 1
Operand - Printer queue name
This command starts the printing process if it not already running. McLaughlin                                                      [Page 2]
5.2 02 - Receive a printer job
+----+-------+----+
| 02 | Queue | LF |
+----+-------+----+
Command code - 2
Operand - Printer queue name
Receiving a job is controlled by a second level of commands.  The
daemon is given commands by sending them over the same connection.
The commands are described in the next section (6).
After this command is sent, the client must read an acknowledgement
octet from the daemon.  A positive acknowledgement is an octet of
zero bits.  A negative acknowledgement is an octet of any other
pattern.
5.3 03 - Send queue state (short)
+----+-------+----+------+----+
| 03 | Queue | SP | List | LF |
+----+-------+----+------+----+
Command code - 3
Operand 1 - Printer queue name
Other operands - User names or job numbers
If the user names or job numbers or both are supplied then only those    jobs for those users or with those numbers will be sent.
The response is an ASCII stream which describes the printer queue.
The stream continues until the connection closes.  Ends of lines are    indicated with ASCII LF control characters.  The lines may also
contain ASCII HT control characters.
5.4 04 - Send queue state (long)
+----+-------+----+------+----+
| 04 | Queue | SP | List | LF |
+----+-------+----+------+----+
Command code - 4
Operand 1 - Printer queue name
Other operands - User names or job numbers
If the user names or job numbers or both are supplied then only those    jobs for those users or with those numbers will be sent.
editor does not contain a
The response is an ASCII stream which describes the printer queue.
The stream continues until the connection closes.  Ends of lines are McLaughlin                                                      [Page 3]
indicated with ASCII LF control characters.  The lines may also
contain ASCII HT control characters.
5.5 05 - Remove jobs
+----+-------+----+-------+----+------+----+
| 05 | Queue | SP | Agent | SP | List | LF |
+----+-------+----+-------+----+------+----+
Command code - 5
Operand 1 - Printer queue name
Operand 2 - User name making request (the agent)
Other operands - User names or job numbers
This command deletes the print jobs from the specified queue which
are listed as the other operands.  If only the agent is given, the
command is to delete the currently active job.  Unless the agent is
"root", it is not possible to delete a job which is not owned by the    user.  This is also the case for specifying user names instead of
numbers.  That is, agent "root" can delete jobs by user name but no
other agents can.
6. Receive job subcommands
These commands  are processed when  the line printer  daemon  has
been given the  receive job command.  The  daemon will continue  to
process commands until the connection is closed.
After a subcommand is sent, the client must wait for an
acknowledgement from the daemon.  A positive acknowledgement is an
octet of zero bits.  A negative acknowledgement is an octet of any
other pattern.
LPR clients SHOULD be able to sent the receive data file and receive    control file subcommands in either order.  LPR servers MUST be able
to receive the control file subcommand first and SHOULD be able to
receive the data file subcommand first.
6.1 01 - Abort job
Command code - 1
+----+----+
| 01 | LF |
+----+----+
No operands should be supplied.  This subcommand will remove any
files which have been created during this "Receive job" command. McLaughlin                                                      [Page 4]
6.2 02 - Receive control file
+----+-------+----+------+----+
| 02 | Count | SP | Name | LF |
+----+-------+----+------+----+
Command code - 2
Operand 1 - Number of bytes in control file
Operand 2 - Name of control file
The control file must be an ASCII stream with the ends of lines
indicated by ASCII LF.  The total number of bytes in the stream is
sent as the first operand.  The name of the control file is sent as
the second.  It should start with ASCII "cfA", followed by a three
digit job number, followed by the host name which has constructed the    control file.  Acknowledgement processing must occur as usual after
the command is sent.
The next "Operand 1" octets over the same TCP connection are the
intended contents of the control file.  Once all of the contents have    been delivered, an octet of zero bits is sent as an indication that
the file being sent is complete.  A second level of acknowledgement
processing must occur at this point.
6.3 03 - Receive data file
+----+-------+----+------+----+
| 03 | Count | SP | Name | LF |
+----+-------+----+------+----+
Command code - 3
Operand 1 - Number of bytes in data file
Operand 2 - Name of data file
The data file may contain any 8 bit values at all.  The total number    of bytes in the stream may be sent as the first operand, otherwise
the field should be cleared to 0.  The name of the data file should
start with ASCII "dfA".  This should be followed by a three digit job    number.  The job number should be followed by the host name which has    constructed the data file.  Interpretation of the contents of the
data file is determined by the contents of the corresponding control    file.  If a data file length has been specified, the next "Operand 1"  octets over the same TCP connection are the intended contents of the    data file.  In this case, once all of the contents have been
delivered, an octet of zero bits is sent as an indication that the
file being sent is complete.  A second level of acknowledgement
processing must occur at this point.
McLaughlin                                                      [Page 5]

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。