Skip to main content

Line Printer Spooler

  • include
  • src
  • Makefile

Running the Program​

  1. Inside the src directory, there is another directory called server. Build the executable using make. Don't keep your expectations high. This server is a really dumb one created as a proof of concept and the things this doesn't do which a lprd should is listed in the source file.

  2. Locate back to the project directory and run make to build the client-side program. Do realize that client attempts to create a TCP/IP connection on port 515. The server is created to run on this port. So if you don't have superuser access on your system, you should consider changing the server's port to something > 1024. Also, make sure that the client's tcp_open function is not called with the service field as printer. Leave the field as a NULL pointer and make sure the port you opened your server is included as the final argument (on send_start function in printbsd.c file.)

  3. Before running the client side program, ensure that /tmp contains a file named seqno which must contain a number. Also, you can use localhost or the network interface that you're connected to. The default name is sroot, which is initialized in initvars.c file. You can: create an entry in /etc/hosts file (if you have sufficient permissions) with your network interface's IPv4 address and hostname as sroot, or you can use different name and change the name in initvars.c file.

  4. Steps that are done by client and server in order:

  5. [server] Initialize the socket using socket call, bind the socket to an network interface (INADDR_ANY in this case). As we're creating a TCP/IP socket, we need to listen on the socket descriptor and spin up an iterative server. The server will now listen for connection.

  6. [client] Calls the send_start function which opens a TCP/IP socket. Do some chores such as: setting the user ID of the program if the binary is set-user-id, get the name of host, check passwd entry for the effective user, open the /tmp/seqno file and lock the file till the operation persists. Through the seqno file, generate the datafile-name and controlfile-name and do some chores regarding the control file. We first send the name of the printer in the form: \002<printer-name>\n to the server. Then we wait for the server to respond with a 1-byte packet which contains a null-byte (\0).

  7. [server] Processes the message sent by client. As we've preceeded the message by the character \002. The server will encounter two scenarios where the message will contain the preceeding \002 character. One of them is sending the name of the printer, and the other one is when sending the control file. For the former case, upon receiving the message with this preceeding character, the server will send a 1-byte message with null-byte as the content. This is what the client is expecting.

  8. [client] Can now start sending the datafile(s). Each datafile which is supplied through the command-line argument is first opened and the content is then sent. Each datafile is processed using send_file function where the actual file transfer is done through xmit_file function. Before invoking xmit_file, some chores regarding control file is first done. Before sending the actual file, a message which contains the first character as \003 is sent to indicate that datafile is about to be transmitted. This message is of the format: \003<file-size> <datafile-name>\n. Then it's waiting a response from the server.

  9. [server] Will get this message and will fetch the file-size and file-name from the message. Next, the size of file is checked to see if it's of considerable size as well as try to dynamically allocate storage to hold the file's content. After all this done, the server will write a 1-byte message which contains the null byte, just as the client is anticipating.

  10. [client] Starts sending the datafile. As the size of the file is already sent, the server will just read the said amount of bytes. After sending all the file's content, the client will write a 1-byte message that contains a null-byte.

  11. [server] Will read exactly the number of bytes as the client previously sent. After reading that amount of bytes, as we are aware of the client sending a null byte, we will read one character and if it's a null byte, we will write back a null-byte as a 1-byte message back. Also, it sets up the variable isctrlinfoready to indicate that any later message with \002 character at the beginning will be the control file.

  12. The communication between client and server from point # 4 through point # 7 is repeated for other data files that the client may have requested to be printed.

  13. [client] After sending all the datafile(s), the send_done function is invoked. We've been builidng up the control file throughout this procedure for this moment. We use xmit_file to transfer the file to the server. As we're sending the control file, we will preceed the message with the character \002. The message sent before sending the control file is of the format: \002<file-size> <controlfile-name>\n. Now, we're awaiting for the server to respond with a 1-byte message containing a null-byte.

  14. [server] Will receive the message sent by client. Since the first character is \002, we know it's a control character, and since we've previously received the datafile(s), the server knows the client is about to send the control file. The message is scanned to determine the file-size and the file-name that the client sent. Like previously with datafile(s), the server will check the file-size and allocate sufficient memory. Now, it writes a 1-byte message containing the null-byte, as the client is expecting.

  15. [client] Upon receiving the null-byte message, will start sending the file content. After all the content of file has been written, the client writes a 1-byte message containing the null-byte. It is now expecting the server to respond back a 1-byte message with null-byte.

  16. [server] Will start reading the file content. As we know the size of the file, we read exactly that amount of bytes. Later we will check to see if the client has sent us the 1-byte message containing the null-byte. If that's the case, then we write a 1-byte message which contains a null byte. If everything goes as expected, the server's function that deals with the client returns 0 to indicate safe error-free handling. The connection is closed by the server.

  17. [client] If the binary was invoked with -d flag in the command-line, will not delete the control file. The connection is closed by the client as well.

Alternative to 4.3BSD Print Spooler​

  1. Modern Unix-Like systems have an successor to System V and 4.3BSD print spooler called Common Unix Printing System (CUPS).

  2. Text showed a command to print files to a printer using the lpr command:

lpr -Plp main.c subr.c

The -P<var> specifies the symbolic name of the printer <var>. Text mentioned "the mapping of symbolic printer names into physical device names, along with a complete specification of the printer's capabilities, is specified by the system administrator in the file /etc/printcap."

The printcap file is no longer used for CUPS.

  1. The symbolic name for the printer can be given using the lpadmin command. The command used to give a symbolic name of DummyPrinter is:
lpadmin -E -p DummyPrinter -v dummy:/tmp/cups/dummyprinter

Here, the -p flag specifies the symbolic name DummyPrinter for the printing device (which is a file /tmp/cups/dummyprinter). Here, the device being used for DummyPrinter is dummy.

  1. dummy above is a custom device created in the /usr/libexec/cups/backend/. The dummy file contains the following script:
#!/bin/sh
OUTPUT_FILE="/tmp/cups/dummyprinter"
cat - > "$OUTPUT_FILE"
exit 0

  1. Although a "dummy" printer with a symbolic name of DummyPrinter is created, assigning job to it--like using the lpr command--will not properly work. The error log pager obtained using the sudo less -f /var/log/cups/error_log command showed that some operations were not permitted. This is likely due to creating our own dummy "protocol" rather than using the one supported. The supported ones are known using the lpinfo -v command.

  2. I won't go further into setting up a dummy printer (for now.) The main focus of this chapter is to understand how job control is done in a network environment.

Actions performed for lpr -Plp main.c subr.c​

  1. You should probably understand the arguments to the command first. This is explained in the previous section.
  2. The two file main.c and subr.c are read by the lpr program and copied to the spooling directory. The name of the spooling directory for a given printer is specified in the /etc/printcap entry for each printer. Assume that for the printer lp the spooling directory is /usr/spool/lpd. Also assume that the symbolic name of the host is orange. The lpr command create three files in the spooling directory
dfA123orange
dfB123orange
cfA123orange

The first is a copy of the file main.c, the second a copy of the file subr.c, and the third file is a "control file" that speicifes the printing parameters for the program that prints the file. We show these spool files in Figure 13.1.

                      user process
                  +--------------+        +------------------+
+--------+        |              |------->| data file        |  /usr/spool/lpd/dfA123orange
| main.c |------->|              |        | (copy of main.c) |
+--------+        |              |        +------------------+
                  |     lpr      |
+--------+        |              |        +------------------+
| subr.c |------->|              |------->| data file        |  /usr/spool/lpd/dfB123orange
+--------+        |              |        | (copy of subr.c) |
                  +--------------+        +------------------+
                                |
                                |         +------------------+
                                +-------->| control file     |  /usr/spool/lpd/cfA123orange
                                          +------------------+

                Figure 13.1  Spool files created by 4.3BSD lpr command

An example of what the control file, cfA123orange, looks like for the example given above is

Horange
Pstevens
Jmain.c
Corange
Lstevens
fdfA123orange
UdfA123orange
Nmain.c
fdfB123orange
UdfB123orange
Nsubr.c

Each line in the control file starts with a letter that specifies a parameter for the printer daemon that eventually prints the file. The characters and their meaning are

f       filename of text file to print
C       class name for banner page
H       name of host system on which the lpr was executed
J       job name for banner page
N       name of file (used by `lpq`)
P       person (login name of user)
U       name of file to unlink after printing is complete

Note that in this example, the first five lines in the control file specify parameters for the entire job, and following these lines are three lines for every file to be printed.

  1. Once the data files and the control file are written to the spooling directory, the lpr process sends an IPC message to the line printer daemon, lpd, notifying it that there is a job to print. The message contains the name of the printer (lp), so the daemon knows which directory to look at for the control files and data files. We show this in Figure 13.2.
            user process
          +-------------------+
          |       lpr         |
          +-------------------+
                  |
                  |  Unix domain IPC message
                  |
                  V
            daemon process
          +-------------------+
          |       lpd         |
          +-------------------+

    Figure 13.2  IPC from lpr process to lpd daemon

The IPC message is sent using a Unix domain stream socket, since the daemon process is running on the same system as the lpr process.

  1. The daemon process, which has been waiting for an IPC message on a Unix domain socket, does a fork of itself. This provides another copy of itself that handles the request, while the original lpd process waits for another IPC message notifying it that there are jobs to print. This is an example of a concurrent server, as described in Section 1.6.

  2. The lpr process is now complete. It has copied the files to be printed to the spooling directory, created a control file for the spooling program, and notified the master print daemon that there is work to do. The forked copy of the printer daemon now looks at the files in the spool directory and sends them to the actual printer. This is shown in Figure 13.3.

                            +-------------------+
                            | data file         |   /usr/spool/lpd/dfA123orange
                            | (copy of main.c)  |
                            +-------------------+
                                    |
                                    |       +-------------------+
                                    |       | data file         |   /usr/spool/lpd/dfB123orange
                                    |       | (copy of subr.c)  |
                                    |       +-------------------+
                                    |               |
                                    |               |       +---------------+
                                    |               |       | control file  |   /usr/spool/lpd/cfA123orange
                                    |               |       +---------------+
                                    |               |               |
                                    |               |               |
                                    |               |               |
                                    V               V               V
daemon process (parent)             daemon process (child)
+---------------------+ (fork)  +---------------------------------------+
|       lpd           |-------->|               lpd                     |
+---------------------+         +---------------------------------------+
                                                |
                                                |
                                                V
                                        printer device

                      Figure 13.3  Processing of spool files by lpd daemon
  1. There are some fine points that were ignored in the description above. First, what if two different users send files to the same printer at almosst same time? This is where the 3-digit sequence number in the df filenames and cf filename is used. Each user's data files and control files have a different sequence number. The assignment of the sequence number is done by each client's lpr process. A file is maintainted in each printer's spooling directory with a 4-character name ".seq". The pathname in the above example would be /usr/spool/lpd/.seq. This file itself has a length of 4 bytes--it contains the next 3 digit sequence number to be used, and a newline. The lpr process opens this file and then calls flock to obtain an "exclusive lock" on the file. The system doesn't return from the flock call until the process has an exclusive lock on the file. Othereise the process is blocked until it can get the lock. When the lpr process obtains the exclusive lock, it reads the sequence number, and uses the value for its data files and control files. It immediately increments this number (cycling back to 000 if its value was 999), writes it back to the file, and close the file. The close system call releases the exclusive lock that the process has on the file, in case another lpr process is waiting to get a lock on the same sequence number file. The actual code fragment to implement this is
sprintf(buf, "%s/.seq", SPOOLDIR);
if ( (fd = open(buf, O_RDWR | O_CREAT, 0661)) < 0)
    err_sys("cannot create %s", buf);

if (flock(fd, LOCK_EX))
    err_sys("cannot lock %s", buf);

seq = 0;
if ( (len = read(fd, buf, sizeof(buf))) > 0) {
    /* 
      file is 4-bytes. `len` will be 4.
      Also, the last character--newline--is not in the range between the 
      ASCII code for numeric digits, so it will likely break out of the 
      loop before the loop itself terminates.
    */
    for (cp = buf; len--; ) {       /* convert ASCII to binary */
      if (*cp < '0' || *cp > '9')
          break;
      seq = seq * 10 + (*cp++ - '0');
    }
}
/* seq = sequence number to use */
seq = (seq + 1) % 1000;                     /* increment seq # modulo 1000 */
/* rewind the file offset that was modified by read */
if (lseek(fd, 0L, 0) < 0)
    err_sys("lseek error");
sprintf(buf, "%03d\n", seq);            /* convert binary to ASCII */
if (write(fd, buf, strlen(buf)) != strlen(buf))
    err_sys("write error");
close(fd);          /* unlocks the file too */
  1. The names of the data files and control files do not conflict for jobs that are destined for different printers, since each printer has its own spooling directory. For example, assume two different printers users executed the lpr program at the same time, one printer on the printer named lp and the other on the printer named laser1. If the sequence numbers for the two printers just happened to be identical (345, for example), then the files are
/usr/spool/lpd/.seq
/usr/spool/lpd/dfA345orange
/usr/spool/lpd/cfA345orange

and

/usr/spool/laser1d/.seq
/usr/spool/laser1d/dfA345orange
/usr/spool/laser1d/cfA345orange

Note that the pathnames of all the files are unique. Note also that since the sequence number files are unique, neither process has to wait for the other to obtain a lock on its sequence number file.

  1. The second point that was ignored above is what happens if there is already a printer daemon process that is busy printing a file on the requested printer. In each printer's spooling directory a file named lock is maintained. Whenever an lpd child process is active for a given printer, that process holds an exclusive lock on its lock file. When a copy of the lpd daemon is forked by the master lpd daemon, the first thing it does is try to obtain an exclusive lock on its lock file. If this fails, and if the reason for the failure is that another process already holds an exclusive lock on the file, then this new copy of lpd daemon gracefully exits, since a copy of the daemon for this particular printer already exists. The actual code segment that implements this is
if ( (lfd = open(MASTERLOCK, O_WRONLY | O_CREAT, 0644)) < 0) {
    /* MASTERLOCK probably a string literal which is `#define`d */
    syslog(LOG_ERR, "%s: %m", MASTERLOCK);
    /* check `syslog(3)` manual for the %m format specifier */
    exit(1);
}
if (flock(lfd, LOCK_EX | LOCK_NB) < 0) {
    if (errno == EWOULDBLOCK)
      exit(0);        /* active daemon present, normal exit */
    syslog(LOG_ERR, "%s: %m", MASTERLOCK);
    exit(1);
}

  1. When a daemon is active for a given printer, it prints all files that appear in the spool directory for that printer. Even though the active copy of the daemon was invoked to print one specific job, when it is done it looks in its spooling directory to see if any other jobs have been placed there for printing.

  2. While the lpd child process has the exclusive lock on its lock file, it maintains the file as an ASCII text file containing two lines. The first line is the process ID of the lpd child process itself, and the second line is the name of the control file for the job currently being printed by the process. By keeping these two peices of information in a file, it is easy for the lpq program to determine if a daemon is active for a given printer, and if so, which job is currently being printed. The way to determine if a process exists, given its process ID, is to use the kill system call and send it a signal 0.

Output Filters​

  1. In essence, the output filter alters the way lpd handles the print job. The four categories for filters: of filter, if filter, /bin/pr, and one of seven possible remaining filter (discussed later) determine how the lpd process will handle the job and tranfer the printing to actual device. The of option is for "per-job" filter, if option for "per-file" accounting (same for one of seven remaining filter and bin/pr). The f in cfA123orange example above is used to describe the control character. Based on the invokation of lpr, the control character can be changed.

  2. The description [previous section] above is valid if there are no output filters being used for the print job. But the 4.3BSD spooliing system supports several different output filters. These handle different types of data files and do resource accounting. The invocation of these filters by the printer daemon provides some interesting uses of process control.

  3. A particular filter is specified with the lpr command. For example, to print the file plot.out that was produced by the Unix plot command on the printer named raster, we execute

lpr -Praster -g plot.out

The -g option causes lpr to change the first character of the control file from an f to a g. When the printer daemon reads the control file, this character tells it which output filter to use.

  1. Figure 13.4 shows the lpr options that cause the different filters to be involved. The interaction of these different filters is not at all obvious from an inspection of Figure 13.4.
+--------+----------+--------------+------------------------------------------------+
| lpr    | printcap | Control file |                 Description                    |
| option | keyword  | character    |                                                |
+--------+----------+--------------+------------------------------------------------+
|        |    of    |              | per-job filter--see description below          |
+--------+----------+--------------+------------------------------------------------+
|        |    if    |      f       | default text filter for per-file accounting    |
|   -l   |    if    |      l       | same as above with "literal" mode              |
+--------+----------+--------------+------------------------------------------------+
|   -p   |          |      p       | use /bin/pr command                            |
+--------+----------+--------------+------------------------------------------------+
|   -c   |    cf    |      c       | cifplot filter                                 |
|   -d   |    df    |      d       | TEX filter                                     |
|   -g   |    gf    |      g       | plot filter                                    |
|   -n   |    nf    |      n       | ditroff filter                                 |
|   -f   |    rf    |      r       | FORTRAN-style output filter                    |
|   -t   |    tf    |      t       | troff filter                                   |
|   -v   |    vf    |      v       | raster filter                                  |
+--------+----------+--------------+------------------------------------------------+

                Figure 13.4  lpr options and filters

MYNOTE: The Control file character section describes the character which can be seen in the name of the control file. For instance, the one which we've been looking previously is cfA123orange. Not really sure what the printcap keyword is and it's significance.

  1. First, group the filters into four categories, as shown above in Figure 13.4.

  2. the of filter

  3. the if filter

  4. the /bin/pr filter

  5. the other seven data filters (the last seven entries in the table)

  6. The -l option to lpr specifies that the file is to be printed in literal mode--control characters are to be printed as is and the usual page breaks (form feeds by default) are not printed. All this option does is pass a special command line option to the if filter, so we can consider it equivalent to the if filter, for our purposes.

  7. The if filter is used by default. It is invoked for every file taht is printed. It usually does the printer accounting function, appending a line to an accounting file specifying the login name and the number of pages printed, for every line.

  8. We can consider the other seven data filters equivalent to the if filter. These seven filters handle special data formats, while the if filter is for text files.

  9. If an if filter or one of the seven special data filters isn't specified for a file, the of filter is used instead. But the of filter is invoked only a single time for a print job, which might be comprised of multiple files.

  10. If the if filter or one of the seven special data filters is being used, the of filter is bypassed, even if it is specified for the printer.

  11. The -p option, to use the Unix /bin/pr program before the file is printed, can be used with the other filters, or by itself.

  12. We can now consider six cases that handle all the different combinations of output filters. These cases are shown in Figure 13.5.

+---------------------+-----------+---------+-------+
| if or other         | of filter | /bin/pr | Case  |
| special data filter |           |         | below |
+---------------------+-----------+---------+-------+
|         no          |     no    |   no    |  (1)  |
|         no          |     yes   |   no    |  (2)  |
|         yes         | (ignored) |   no    |  (3)  |
|         no          |     no    |   yes   |  (4)  |
|         no          |     yes   |   yes   |  (5)  |
|         yes         | (ignored) |   yes   |  (6)  |
+---------------------+-----------+---------+-------+ 

Figure 13.5  Cases to consider for combinations of filters

  1. [Case 1] This case was shown in the example earlier in this section. The lpd daemon spawns a child process that prints all the data files on the printer device. No filters are involved.

  2. [Case 2] When only an of filter is specified, the lpd child process first creates a pipe and then forks to create another process. This new child process uses the dup system call to assign the output end of the pipe to its standard input and to assign the printer device to its standard output. It then execs the filter program. The lpd child reads each data file and writes to the pipe for the filter process to print. We show this in Figure 13.6.

          control file 
          data files
            |
            |
            V
    fork  +-----------+   fork        +-----------+   fd = 1
  ------->|   lpd     |-------------->|   of      |----------> printer device
          |   (child) |   exec        |   filter  |
          +-----------+               +-----------+
            |                               ^
            |                               | fd = 0
            |       +-------+               |
            +------>| pipe  |---------------+
                      +-------+
          
    Figure 13.6  Process and IPC for only an of filter
  1. [Case 3] When either an if filter or one of the seven special data filters is specified, the output filter is invoked for every file to print. Also, even if an of filter was specified, it is not used. Before invoking the filter, the lpd child uses the dup system call to attach the input data file to its standard input, and the printer device to its standard output. This is shown in Figure 13.7.
                            +---------------------------------------------------------------+
            control file    |                                                               |
            data files      |                data files                                     |
                |           |                    |                                          |
                |           |                    | fd = 0                                   |
                V           |                    V                                          |
    fork    +-----------+   |    fork        +-----------+   fd = 1                         |
----------->|   lpd     |---|--------------->|   filter  |------------> printer device      |
            |   (child) |   |    exec        +-----------+                                  |
            +-----------+   |                                                               |
                            |                                                               |
                            |                                                               |
                            +---------------------------------------------------------------+
                                              once per data file

                      Figure 13.7  Processes and IPC for if or other data filter
  1. [Case 4] If the /bin/pr program is used as a filter, without an if or an of filter, we have the same case as the previous, with the /bin/pr program being used as the output filter. Figure 13.8 shows this case.
                            +---------------------------------------------------------------+
            control file    |                                                               |
            data files      |                data files                                     |
                |           |                    |                                          |
                |           |                    | fd = 0                                   |
                V           |                    V                                          |
    fork    +-----------+   |    fork        +-----------+   fd = 1                         |
----------->|   lpd     |---|--------------->|  /bin/pr  |------------> printer device      |
            |   (child) |   |    exec        +-----------+                                  |
            +-----------+   |                                                               |
                            |                                                               |
                            |                                                               |
                            +---------------------------------------------------------------+
                                              once per data file

                      Figure 13.8  Processes and IPC for /bin/pr without other filters

Since the /bin/pr program reads from its standard input and writes to its standard output, it can be used just like the printer specific filters.

  1. [Case 5] When we have two filters between the lpd child process and printer device (the /bin/pr filter and the of filter), the two filters must be connected with some form of IPC. The technique used is a pipe. The first step is for the lpd child to create a pipe using the pipe system call, fork a copy of itself, and then exec the of filter. These are exactly the same steps used in case 2. This is shown in Figure 13.9. This first step is done only once by the lpd child.
          control file 
          data files
            |
            |
            V
    fork  +-----------+   fork        +-----------+   fd = 1
  ------->|   lpd     |-------------->|   of      |----------> printer device
          |   (child) |   exec        |   filter  |
          +-----------+               +-----------+
            |                               ^
            |                               | fd = 0
            |       +-------+               |
            +------>| pipe  |---------------+
                    +-------+

          Figure 13.9  First step when two filters are being used

Then, for every data to be printed, the /bin/pr filter is invoked. This is done by forking and execing the /bin/pr filter, having it use the previously created pipe for its standard output, and the data file as its standard input. We show this in Figure 13.10.

                            +---------------------------------------+
            control file    |                                       |
            data files      |                data files             |
                |           |                    |                  |
                |           |                    | fd = 0           |
                V           |                    V                  |
    fork    +-----------+   |    fork        +-----------+          |           +-----------+  fd = 1
----------->|   lpd     |---|--------------->|  /bin/pr  |          |           |   of      |----------> printer device
            |   (child) |   |    exec        +-----------+          |           |   filter  |
            +-----------+   |                        |              |           +-----------+
                            |                        | fd = 1       |                 ^
                            |                        |              |                 | fd = 0
                            +------------------------|--------------+                 |
                                once per data file   |                                |
                                                     |           +----------+         |
                                                     +---------->|  pipe    |---------+
                                                                 +----------+

                      Figure 13.10  Final arrangement when two filters are used
  1. [Case 6] The final case involves two filters between the lpd child and the printer device, but unlike the previous case, now both of these filters are invoked for every data file. Again, a pipeline is used as the form of IPC between the two filters. For each data file, the first step is to create a pipe and then fork and exec the /bin/pr program, connecting the pipe from /bin/pr back to the lpd child process. Figure 13.11 shows this arrangement. Note that the data file to be printed is attached to the standard data input of the /bin/pr filter.
          control file 
          data files                  data file 
            |                           |
            |                           | fd = 0
            V                           V
    fork  +-----------+   fork        +-------------+
  ------->|   lpd     |-------------->|   /bin/pr   |
          |   (child) |   exec        |             |
          +-----------+               +-------------+
            ^                               |
            | fd = 0                        | fd = 1
            |       +-------+               |
            +-------| pipe  |<--------------+
                    +-------+

    Figure 13.11  First step when two filters are invoked for every data file

Next the lpd child process spawns the filter program, setting up the file descriptors before the exec so that the standard input for the filter is the pipe and the standard output is the printer device. This final arrangement is shown in Figure 13.12.

                           +--------------------------------------------------------------------------------+
            control file   |                                                                                |
            data files     |                                                        data file               |
                |          |                                                            |                   |
                |          |                                                            | fd = 0            |
                V          |                                                            V                   |
    fork  +-------------+  |    fork     +----------+                               +---------+             |
--------->|     lpd     |--|------------>|  filter  |                               | /bin/pr |             |
          |    (child)  |  |    exec     +----------+                               +---------+             |
          +-------------+  |                |    ^                                      |                   |
                           |         fd = 1 |    | fd = 0                               | fd = 1            |
                           |                |    |          +------+                    |                   |
                           |                |    +----------| pipe |<-------------------+                   |
                           |                |               +------+                                        |
                           |                V                                                               |
                           |            printer device                                                      |
                           |                                                                                |
                           +--------------------------------------------------------------------------------+
                                                         once per data file

                        Figure 13.12  Final arrangement when two filters are invoked for every file

For simplicity, we do not show that the lpd process opens the printer's log file on its standard error before execing any of the filters. By doing this, any of the filters can write error messages to their standard error.

Remote Printing​

  1. We now consider a request to print a file on a printer that resides on a remote host. The system administrator can set a flag for a printer in the /etc/printcap file that designates the printer as a remote printer and specifies the name of the remote host to send files to for printing. It is transparent to the users of the lpr command that the actual printer is connected to a different computer system. If we assume that the name of the local system (the system on which the lpr command is executed) is named orange and that the remote system (the one on which the files are printed) is named apple, we can pick up the example from above at the pointer where the master lpd daemon has forked a copy of itself to handle the request. The lpd child process recognizes that the request is for a remote printer from the printer's entry in the /etc/printcap file. Instead of sending it to the printer device, it opens a TCP connection to the printer service on the remote host, which is the lpd daemon on a 4.3BSD system. This gives us the processes shown in Figure 13.13. (The service name printer is converted to its TCP port number using the getservbyname function, described in 8.2.).
+---------------------------------------+                       +-------------------------------------------+
|                                       |                       |                                           |
|   +-------+                           |                       |                                           |
|   | lpr   |---------> control file    |                       |                                           |
|   +-------+           data files      |                       |                                           |
|       |                   |           |                       |                                           |
|  UNIX | domain IPC        |           |                       |                                           |
|       |                   |           |                       |                                           |
|       V                   V           |                       |                                           |
|   +-----------+       +-----------+   |   Internet domain     |   +-------------+  fork  +-------------+  |
|   | local lpd | fork  | local lpd |<--|-----------------------|-->| remote lpd  |------->| remote lpd  |  |
|   |  (parent) |------>|  (child)  |   |       IPC             |   | daemon      |        | (child)     |  |
|   +-----------+       +-----------+   |                       |   +-------------+        +-------------+  |
|                                       |                       |                                           |
+---------------------------------------+                       +-------------------------------------------+
          local host orange                                                   remote host apple

                            Figure 13.13  Processes and IPC for remote printing

  1. The master lpd daemon on the remote host is waiting for one of two events to occur

  2. a local connection on a Unix domain socket from a local lpr command, as described previously.

  3. a remote connection on an Internet domain socket from a remote lpd daemon, which we now describe.

  4. The lpd process uses the select system call to wait for either connection to occur. When a remote connection is received, the remote lpd daemon first verifies that the sending host has permission to send it print jobs, and then forks a copy of itself. As before, it is the child process that does the actual work, allowing the parent to go back to its wait for a socket connection. This is another example of concurrent server as shown in Figure 13.14.

+-----------+   Internet domain IPC   +------------+
| local lpd |<----------------------->| remote lpd |
| (child)   |                         | (child)    |
+-----------+                         +------------+

    Figure 13.14  Actual communication is between the two child process for remote printing
  1. The first communication across the socket occurs when the local process writes the following 4 bytes to the socket
\002lp\n

This line consists of a byte containing the binary value 2 (shown above as \002), followed by the ASCII name of the printer (lp in this example), followed by a newline. This is the standard format for IPC messages to or from the daemon: a binary byte that specifies the message type, followed by the variable-length ASCII message, follwed by a newline. Acknowledgements usually consist of a single byte, with a byte of binary zero meaning all is OK, and other values indicating various error conditions. The first byte of this message, 2, specifies that the local host wants to send the remote daemon one or more files to print. This line is read by the remote process and it writes an acknowledgement message to the socket consisting of a single byte of zero. The local process now sends the data files to be printed, followed by the control file, to the remote process.

  1. The actual data flow [for sending files to the server] is:

  2. The local writes a message of the form

    \003size filename\n

    to the remote process. The message type, 3, specifies that a data file is being sent. The first file transferred in our exmaple is main.c. By specifying its size in bytes, the remote system can check that it has enough room for the file. Knowing the size before the file transfer also allows the receiving process to know when it has received the entire file. The filename in our example is dfA123orange. Note that the first line that was transferred across the socket between the two daemons specified the name of the destination printer (lp), so the receiving daemon can write the data file to the appropriate spool directory on the remote system. There is no need that the spool directory on the remote system be the same as on the remote system. The /etc/printcap file on the remote system contains all the parameters for the remote spooling system.

    Note also that there cannot be filename conflicts in the remote spool directory with print files arriving from multiple hosts, each with their own sequence numbers. (Recall that the sequence number is assigned by the local host.) This is because the filename in the remote spool directory contains the host name.

  3. If there is room on the remote system, the remote process responds with an acknowledgement consisting of a single byte of zero. If the file won't fit, the response is a single byte of two.

  4. If there is room on the remote host, the local host now sends the actual data file. The entire file is transferred across the socket, followed by a byte of zero. Since the receiving host knows the size of the file, it knows when the entire file has been received. Note also that since the size of the file is known by the receiver before the file is transferred, there are no restrictions on what characters can be in the file. Either text files or binary files can be handled.

  5. If the remote host receives the entire file and the final byte of zero, it responds with an acknowledgement of a byte of zero, otherwise it responds with a single byte of one.

  6. Note that the network protocol being used by the two processes, TCP, is a reliable protocol with error handling built into it. The simple application protocol that we described above is between the two application processes (the two daemons). There are no checksums or block numbers specifically sent by the daemons in their messages--this is handled by TCP.

The four steps listed above (in previous point) are then repeated for the next data file, dfB123orange, which is a copy of the file subr.c, and then repeated again for the control file, cfA123orange. When the control file is transferred, the first byte of the message in step 1 is 2, instead of 3 (i.e., \002size <control-filename>\n), indicating that the file is a control file and not a data file. Once the files are successfully transferred to the remote system, they can be deleted from the local system. The local process goes through the control file and for every U line, unlinks the corresponding file. The control file is then deleted.

  1. Before closing the socket connection to the remote host, the local process first checks if any other print jobs have arrived that are to be sent to the remote host. If so, they are transferred. When there are no more jobs to transfer to the remote host, the local process terminates, which closes the socket. The remote process, which has executed a read on the socket, waiting for some more files to be transferred, gets an end-of-file return from the read. It then goes through its spool directory and prints the files that have been queued (i.e., the jobs that it received from the local host, along with any other jobs that are queued for the lp printer).

Two copies of the file are made when the file is printed on a remote printer. The first is made by the lpr process on the local host, and the other copy is made by the remote lpd daemon when it receives the file. Doing it this way makes it transparent to the local lpr process that the file is going to a remote host--the only process that needs to worry about sending the file to the remote host is the lpd process. Also, another benefit of the additional copy is that it is transparent to the local lpr process if the remote host is not available. The file is still spooled on the local system and can be transferred to the remote system by the lpd daemon as soon as the remote host is available. If we wanted to avoid the extra copy that is made, the lpr process would have to handle the transmission to the remote host and it would not be able to do the transfer if the remote host were down.

Security Issues for Remote Printing​

  1. We gave an overview of the network security used by 4.3BSD in Section 9.2. Figure 9.1 listed the steps taken by the lpd server. The steps are

  2. First, any request from a remote host to access a printer must arrive with a reserved TCP port number. (Reserved Internet ports were discussed in Section 6.8.)

  3. Next, the remote host must appear in either the file /etc/hosts.equiv or the file /etc/hosts.lpd. If a host is not considered an equivalent host (probably talking about /etc/hosts.equiv) for the rshd and rlogind servers (which we describe in Chapters 14 and 15), you can still give it access to your line printers by entering the host name in your /etc/hosts.lpd file. This file is used only by the printer daemon, to allow printer access to nonequivalent hosts.

  4. Finally, the administrator has the option of specifying an option in the /etc/printcap file for any printer that restricts remote usage of the printer to users with accounts on the server's system. This option is handled by the lpd daemon. Recall from the comments in the _validuser function that we showed in Section 9.2, that the line printer server calls this function to validate a login name.

Ancillary Daemon Functions​

  1. We described in detail one IPC message that the master lpd daemon handles
\002printer\n

This line was read by the daemon on its Internet domain socket and asked the daemono to receive one or more files from a remote system for queueing on the local system.

  1. The five message lines of this [above shown] form that the daemon handles are as follows:

  2. check the queue for jobs and print any that are there,

  3. receive a job from a remote system,

  4. list the queue, short form,

  5. list the queue, long form,

  6. remove some jobs from the queue.

Step 2 from the first example of this chapter, when the lpr process sent a Unix domain message to the daemon after placing a job in the queue for a printer, sends the first of these messages to the daemon. The third and fourth messages are used by the lpq program to print the status of the queue for a given printer. The final message is used by the lprm program to remove a job from a print queue. The three programs, lpr, lpq, and lprm are the ones available for general users.

  1. An additional program, /etc/lpc is available for the system administrator for additional control over the spooling system. The commands provided by this program are

  2. abort: Kills an existing daemon (if one exists) and disables printing for one or more printers. The method used to disable printing is to turn on the owner-execute bit of the lock file in the spooling directory for a given printer.

  3. start: Enables printing and starts a daemon for one or more printers. This command turns off the owner-execute bit of the lock file in the spooling directory.

  4. clean: Remove any control files, data files, and temporary files that do not form a complete print job.

  5. enable: Enables lpr to queue jobs for one or more printers. Queueing is enabled for a given printer if the group-execute bit of the lock file in the printer's spool directory is off.

  6. disable: Disables queueing of print jobs by lpr by turning on the group-execute bit of the lock file in a printer's spool directory.

  7. restart: Attempts to start a new lpd child process for a given printer.

  8. stop: Stops an lpd child process after the current job completes, then disables printing on the printer.

  9. up: Enables queueing and enables printing for a given printer.

  10. down: Turns queueing off and disables printing for a given printer.

  11. topq: Moves one or more print jobs to the top of the queue for a given printer. Since the processing of a printer's queue is done in a first-in, first-out order, based on the modification time of a job's control file, this command changes the modificaiton time of the specified job's control files. Additionally, the world-execute bit of the printer's lock file is turned on to tell the lpd child process that the output queue for this printer must be rebuilt when it is finished with the current job.

  12. status: Displays the status of a given printer--queueing status, printing status, number of jobs to print, and whether an lpd child process is active for the printer.

  13. The features that a system administrator needs control over--enabling and disabling the queue for a printer, and starting and stopping a printer--are controlled by the owner-execute bit and the group-execute bit of the printer's lock file. Recall that the lpd child process for a given printer holds an exclusive lock on its lock file while it is active. Having the file locked by the lpd child process does not prevent the lpc process from modifying these execute bits in the file's access control word. Hence, a printer's lock file is used for six different purposes.

  14. The file is exclusively locked by an active lpd child process, to prevent multiple daemons from being invoked.

  15. If the owner-execute bit is on, printing is disabled.

  16. If the group-execute bit is on, queueing is disabled.

  17. If the world-execute bit is on, the lpd child process is to rebuild the queue after it is finished with the current job.

  18. The first line of the file is the ASCII process ID of the lpd child process, and is used by lpc to kill this process when turning a printer off.

  19. The second line is the name of the control file of the job being printed, and is used by the lpq process.

System V Print Spooler​

  1. There are some changes as compared to the 4.3BSD Line Printer Spooler. One of the changes is the command which is used by the client to print any file on a printer. The command used is lp command which communicates with the lpsched daemon found in System V. The command is of the form:
lp -plaser1 main.c subr.c

The -p flag is used to indicate the printer which is used for printing the files: main.c and subr.c.

Another thing that wasn't previously mentioned is, instead of using a specific printer like laser1 in the above example, one could also queue a print job using the printer class name. System V takes the naming one step further and allows names to be associated both with printers and with classes printers. For example, we can create a class of printers with the name laser that might include 3 different printers. We then specify either a specific printer, perhaps, laser1, laser2, or laser3, or the class name, in which case the system prints the job on the first avaiable printer in the class.

  1. The working of the lp command is similar to the lpr we recently discussed. The text does mention that links are made to the files to be printed. That probably means that instead of copying the filename and its content, the ln/link command may be used to create either a symbolic link or a hard link (I think the former one is more appropriate). But if the link cannot be made (if the files are on a different filesystem from the /usr/spool/lp directory), then the full pathname of the two files is remembered by lp. Also, an option can be specified to have lp make a copy of the files and print the copy. If a copy is not made, then any modifications made to the files before they are printed will appear in the printed output (my reason to belive that the lp commands symbolically links the file rather than a hard link). For the example above, the spool files created can be represented as:

(Assuming links can be made to the user's files, three files are created by lp in the directory /usr/spool/lp/request/laser1).

                                                +-------------------+
                  user process          +------>| data file         |   /usr/spool/lp/request/laser1/d5-123
+--------+        +---------+           |       | (link to main.c)  |
| main.c |------->|         |-----------+       +-------------------+
+--------+        |         |                   
                  |         |                   +-------------------+
                  |     lp  |------------------>| data file         |   /usr/spool/lp/request/laser1/d6-123
                  |         |                   | (link to subr.c)  |
+--------+        |         |                   +-------------------+
| subr.c |------->|         |-----------+
+--------+        +---------+           |       +-------------------+
                                        +------>| request file      |   /usr/spool/lp/request/laser1/r-123
                                                +-------------------+

                      Figure 13.15  Spool files created by System V lp command

  1. There exist some filesystem restriction on System V's lp command as compared to 4.3BSD's lpr command. The System V line printer spooler requires that all directories and files start at the /usr/spool/lp directory, while the 4.3BSD only requires the file /etc/printcap to be in a known location, with all spool directories pointed to by the printcap file.

  2. Similar to the "control" file for lpr, the lp command works on the "request" file, which specifies the parameters for the print job. An example of what the request file looks like is:

T
C 1
O
F d5-123
F d6-123

Each line in the request file starts with a letter that specifies a parameter for the printer daemon.

C       number of copies, -n option
F       name of file to print
O       printer-specific options, -o option
T       optional title, -t option

  1. As with the 4.3BSD spooler, a sequence number is chosen for each print job by the lp command. Unlike the 4.3BSD system, the System V spooler uses a single sequence number file for all print jobs. The 4.3BSD system uses a separate sequence number file for each printer. A locking mechanism makes certain that multiple invocations of lp don't interfere with each other in obtaining the next sequence number. In the example above we assume the sequence number is 123. The names of the data files (the names of the links to the data files) are of the form dn-seqno where n is an integer that is incremented for every job that gets printed (the numbers 5 and 6 in our example) and seqno is the sequence number.

  2. An entry is appended to the file /usr/spool/lp/outputq. This is a binary file whose function is described in page 560/561 of text.

  3. The System V line printer system uses a FIFO (named pipe) to commuincate between the user's lp processes and the system's printer daemon lpsched. After creating a request file and any required data files, the lp process writes a single line to the file /usr/spool/lp/FIFO which is a FIFO. In our example the line could be

r laser1 123 stevens\n

The first character, r, specifies that this is a print request (the FIFO is used for other messages between other processes and the daemon) and it is followed by the destination name (laser1), the sequence number and the name of the user who executed the lp command. The second and third parameters allow the daemon to go to the file /usr/spool/lp/request/laser1/r-123 to find the request file for this job. We specifically show the newline character at the end, as these are used as the message delimiters for the data in the FIFO. The communication between the user process and the daemon is shown in Figure 13.16.

    user process                                    daemon process
+-----------------+                             +--------------------+
|       lp        |                             |       lpsched      |
+-----------------+                             +--------------------+
          |                                                   ^
          |                                                   |
          |                    FIFO                           |
          |               +-----------+                       |
          +-------------->|           |-----------------------+
                          +-----------+
                        /usr/spool/lp/FIFO

            Figure 13.16  IPC through FIFO between lp and lpsched daemon

  1. After writing to the FIFO the lp process is finished. Note that multiple lp processes that might be executing at the same time have their writes to the FIFO handled correctly by the kernel. Recall from Section 3.5 that writes to a pipe or FIFO are guaranteed to be atomic, when the size of the write is less than the capacity of the FIFO, as it is here.

  2. We now follow the actions of the system printer daemon, lpsched, when it receives a request to print a job. As with the 4.3BSD daemon, it does a fork to have a child process handle each job, but the actions of the System V daemon are more complicated.

  3. If the requested printer is not busy, and it is enabled for printing, the daemon forks a copy of itself, and the "master" daemon (the parent) goes back to waiting for a request to be written to the FIFO. The parent remembers that the printer is now busy and it also remembers the process ID of the child process, so that it can wait for it later.

  4. The child process (we'll call it the first child) opens and reads the request file. It builds a command line that is used for executing the interface program for the specified printer. In our example the command line is

    interface/laser1 laser1-123 stevens "" 1 "" /usr/spool/lp/request/laser1/d5-123 /usr/spool/lp/request/laser1/d6-123

    (The line above may be rendered as two lines, depending on the screen size.) The interface program expects its arguments to be as shown in Figure 13.17.

    +----------+--------------------------------------------------------------------------------+
    | Argument |                    Description                                                 |
    +----------+--------------------------------------------------------------------------------+
    |    0     | Name of the interface program. The interface program can obtain the name of    |
    |          | the printer from the last portion of this argument, using the Unix `basename`  | 
    |          | command, for example.                                                          |
    +----------+--------------------------------------------------------------------------------+
    |    1     | Request name.                                                                  |
    +----------+--------------------------------------------------------------------------------+
    |    2     | Login name.                                                                    |
    +----------+--------------------------------------------------------------------------------+
    |    3     | Title. Shown above as an empty string.                                         |
    +----------+--------------------------------------------------------------------------------+
    |    4     | Number of copies to print.                                                     |
    +----------+--------------------------------------------------------------------------------+
    |    5     | Options. Shown above as an empty string. This is where the `-o` options on     |
    |          | the `lp` command are passed to the actual interface program.                   |
    +----------+--------------------------------------------------------------------------------+
    |    6     | First file to print.                                                           |
    +----------+--------------------------------------------------------------------------------+
    |    7     | Second file to print.                                                          |
    +----------+--------------------------------------------------------------------------------+
    |   ...    |                                                                                |
    +----------+--------------------------------------------------------------------------------+

                Figure 13.17  Command line arguments to printer interface program

    (The first column in Figure 13.17, 0, 1, etc., is the index of the argument. In a C program the arguments would be argv[0], argv[1], and so on.) The first child opens the actual printer device and attaches it to both standard ouput and standard error. The standard input is attached to the empty device /dev/null, in case the interface program attempts to read from standard input. If the device's file permission bit allows reading, then both standard output and standard error are opened for reading and writing. Otherwise, they are opened for writing only. The attempt to open the device for reading is for those devices that present status information that the interface program might want to read. (The 4.3BSD print spooler has a similar feature that is specified as a per-printer option in the /etc/printcap entry for each printer.)

    The first child does another fork and it is the second child that does the exec of the interface program, using a command line as shown above.

  5. The second child does the exec and the first child waits for the interface program to complete. It is the interface program that reads the files to be printed and prints them. Most interface programs are shell scripts, and you can look at them by perusing through the files in /usr/spool/lp/interface. Note that there is no assumption by anyone whether the interface program is a shell script, a C program, or any other type of program--if a program can be execed and passed an argument list, it can be an interface program.

    When the second child has finished and calls exit, the first child has its wait return. The first child then deletes the request file and any data files that it created in the spool directory (the files laser1/d5-123 and laser1/d6-123 from the example). It then sends an IPC message back to the master daemon (the parent) notifying it that the specified printer has finished and is ready for more output.

    The picture we have from these steps is shown in Figure 13.18.

                      +---------+
      FIFO----------->| lpsched |---------+
                      +---------+         |
                                          | fork
                                          V
                                    +---------------+
                                    | lpsched       |
                                    | (first child) |
                                    +---------------+
                                        ^       |
                                        |       |
                                        |       | fork
                    +-------------------+       |
                    |                           V
            +--------------+            +----------------+
            | request file |            | lpsched        |--------------+
            +--------------+            | (second child) |              |
    /usr/spool/lp/request/laser1/r-123  +----------------+              |
                                                                        | exec
                                                                        V
                                                            +-----------------------+
                                                            |   printer interface   |
                                                            |   program             |
                                                            +-----------------------+
          +-------------------+                                   ^       ^       |
          | data file         |                                   |       |       |
          | (link to main.c)  |-----------------------------------+       |       |                     
          +-------------------+                                           |       |
      /usr/spool/lp/request/laser1/d5-123                                 |       |
                                                                          |       |
          +-------------------+                                           |       |
          | data file         |                                           |       |
          | (link to subr.c)  |-------------------------------------------+       |
          +-------------------+                                                   |
      /usr/spool/lp/request/laser1/d6-123                                         |
                                                                                  V
                                                                            printer device

                Figure 13.18  Processes and files used by System V print spooler

    One point to note is that there is no requirement that the interface program print anything. What is provided by the System V line printer spooler is a general purpose scheduler that could be used for purposes other than printing files on a line printer. Since it is easy to implement your own interface programs, you can have them do whatever you wish. Be aware that there are some basic limitations in the scheduling algorithms currently used by the spooler--for example, you cannot assign priorities to different requests, and you cannot have the spooler process the jobs in any order other than first-in, first-out.

    When the master printer daemon is started, usually from the file /etc/rc during system initialization, it creates a file named /usr/spool/lp/SCHEDLOCK and locks this file. This is to prevent any additional copies of this daemon from starting, as long as the original daemon is still in existence. This same technique was used by the 4.3BSD daemon and it is a standard technique that programs can use to assure that only a single copy is running.

  6. The last paragraph from the previous points provides a good way for a programmar to create a daemon, or rather a "master" daemon. When the daemon process first runs, it can open a file, like /path/to/process/MYDAEMON, and then obtain an exclusive lock for that file. This way, one can assure that multiple copies of master daemon cannot be run simultaneously. Normally, the call to open would be in a "blocking" state as we are opening a file with the exclusive lock. To avoid this, we can specify a non-blocking flag which allows the system call to immediately return if the file can't be opened.

  7. The Ancillary Daemon Functions Section of the text is not presented here. Interested reader could refer to page 559 of the text.

  8. There are three exercises given in the text. These questions are similar, they ask for some implementation techniques that can be used for, say, a lp client to initiate a job on a printer attached to a 4.3BSD system. Also, another question, but for lpr client and printer attached to System V machine. The last question is about using lp program to print a file on a printer attached to another System V machine using the TCP/IP link. The last question plays a crucial role as it drives the reader to implement a lpd style daemon which is capable of listening to Internet domain sockets. Like how the lpd functions, we can make the my_lpsched_mini daemon to listen to a reserved port where the client can request for a print job. The client uses lp command to make a print job and required files (data files and request files). The client can then send this information over the Internet socket and print the files. Of course there are a lot of details that has not been considered, but the answer only attempts to cover the focal point of the question. For the first two questions, we need some way to create appropriate control/request file, depending on which system the printer is attached to. For 4.3BSD system that is attached to the printer and the client uses lp program, we can make some modifications such that data files and "request" files are compatible with the lpd that the 4.3BSD uses. The name of the data files must be appropriately modified, as well as content of "request" file such that it resembles the "control" file the lpd uses. Likewise, similar strategy can be used for a lpr client which is used for communicating with the lpsched daemon on a System V machine which is attached to a printer. There are no solutions provided for these exercises, as even if there was some solution, verification could not be done by me because: (1) lack of System V/4.3BSD machine and (2) I don't own a printer (and most printers seems to have their own application protocol, IPP).

Extras​

  1. printcap file format manual: https://man.freebsd.org/cgi/man.cgi?query=printcap&sektion=5&format=html
  2. IPP: RFC 2565

Contents

Edit this page