Direct socket printing (such as HP JetDirect on 9100/tcp) by accepting only one TCP connection on the socket exploits the rate adaptation and logical end of file inherent in TCP. With this scheme it can start processing the input as soon as it starts to receive it.
The RFC 1179 Line Printer Daemon protocol traditionally accepted multiple jobs which it received before they were printed. I.e. Simultaneous Peripheral Operations On-Line (according to AST) to prevent user programs tying up the single line printer. The real problem now (with other LPD implementations and CUPS) is queues tying up the sysadmin. Now LPD is built in to printers and large PostScript (vector or super massive PCL uncompressed bitmap) jobs are being SPOOLed and then processed in memory rather than on mass storage. The problem with LPD is resources are finite and there is no official way of limiting the rate at which jobs are submitted. A LPD may have these one byte replies. \000 Accepted \001 Not accepting new jobs, tell sysadmin it has died again \002 Counts exceed allocated or available space, try later \003 Bad job format Rather than return \002 it may also just stop reading the socket until space is available again. This must always be done if it only finds out in the middle of receiving a print job. (Once picked up a job must be completed until logical end of file. You don't want to permanently block these.) Note that RFC 1179 only mentions zero or non-zero replies. There is no mention of the \002 reply or rate adaptation. Rejection including \002 may cause other LPDs to stop accepting. For this reason blocking the socket is common. A default timeout of 30000 s would be 8 h and 20 min and may work. The user can always interrupt or kill it. http://www.ietf.org/rfc/rfc1179.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
