11.8. Problems With Network Print Servers

Most of the Network Print Servers are implemented using extremely simply software. The following is a list of some problems and what options the LPRng software uses to handle them.

11.8.1. Network Print Server Not Responding

Only a single TCP/IP connection is accepted at a time. This means that when one user is sending a job then the unit will not accept other connections. There is another side effect of this problem, which is that some implementations will accept a network connection but not read any data from the connection until the previous connection is finished.

The deal with these problems the connect_timeout, send_job_rw_timeout, and send_query_rw_timeout are used to control job transfer and lpq status gathering. See Printing Job Files and Opening the Output Device for details.

11.8.2. Network Print Server Does Not Handle LPQ, LPRM

Some Network Print Servers do not respond to lpq or lprm queries correctly. The remote_support option can be used to solve this problem by specifying what operations the remote print server can handle:

:remote_support=RMQVC
  R = lpr, M = lprmg, Q = lpq, V = lpq -v, C = lpc
  :remote_support=R  # printer only handles LPR

11.8.3. Incomplete Job Transfers

This is the result of a defective or buggy TCP/IP stacks. A common problem is the habit that some Network Print Servers occaisionally discard data at the end of a print job when a network connection is half-closed. A half-closed connection is one where one end of the sending connection indicates that no further data will be sent. Unfortunately, the Network Print Server will then try to close the connection in the other direction. When this does not immediately succeed, it will terminate the network connection, discarding any unprinted data.

The half_close flag can be used to solve this problem. See Normal Termination for more details.

lp:lp=lp@remote        # shutdown(fd,WRITE) connection, wait for end
lp:lp=lp@remote:half_close@    # close() connection and do not wait