New LPD module in RPM 6.2

LPD is the print protocol utilized across the Internet since some time before 1990. RPM Remote Print Manager® ("RPM") of course has handled LPD since its beginning.

With this release, we set about to create a new LPD module which focused on reliability, clarity, and performance. Internally we call it "lpd2" since it's a new architecture, at least in the way we put it together. It's not strictly the second iteration but the second we've done since the RPM 5.0 version which was a complete rewrite of everything.

Here are the main considerations for this new LPD handling module.

Support for Microsoft byte counting

Probably nothing has tripped us up as much as setting up a Microsoft "print to LPR" port for use with a printer, only to find jobs not processing in RPM. Now when a job data size claims to be 4GB or more, we assume it's probably from an LPR client which didn't want to spool the print job so that it can send a byte count first. That's perfectly fine; we know what to do.

Multiple control and data files

We now handle multiple control files in a job, and multiple data files, and combinations thereof. Some Linux clients use this as a way of sending multiple print jobs on a single connection. It's faster than opening a new connection for each print job and it's perfectly legal.

Support for AS/400 extensions

RPM now supports AS/400 specific LPD subcommands. We also have supported extended control file commands for years now.

LPD stream support

RPM supports the so-called "LPD stream" where the data size is said to be zero. This is another way of handling the "don't count the data bytes first" problem.

Introduced Capture support

We've added a "capture" feature which writes the overhead part of the LPD protocol to a file, which we can then replay. This is intended to help us understand unexpected job behavior not related to the actual data. It does not (at this writing) include the actual job data, rather a representation which we can use to synthesize a fake job. 

End of data issues

We added support to resolve a problem we've seen at the end of extremely large jobs, where sometimes the end of the job data didn't arrive with the rest of the data. We coaxed it a bit and now it works as expected.

Control file order

We had put a lot of attention into handling all the parts of the LPD job without relying on order, only to find that if the control file came first, it was overriding the size of the data file when it comes to the final job record, the one that appears in the UI. The actual size of the data file was unaffected. This is fixed.

Null characters no longer an issue

Some print clients, notoriously the Microsoft LPR client, append a null character to the control file and the data file. We meant to trim that NULL character from the data like we did in the previous RPM but apparently missed coffee that day. This is now fixed. This was apparently causing problems for some clients using the Raw Print action, depending of course on the printer.

Also, if there are "extra" bytes like that NULL appended to either the control or data files, we now mention this in the diagnostic log.

Unexpected characters in names

We now account for non-ASCII characters in the control file names. Some Linux clients increment a character without apparent limitation if you send multiple files on a single print request.

Lpstat results

  • We were transmitting the results of "lpstat" commands but the clients weren't getting them. We got our act together and now both Linux and the Windows "lpstat" clients receive our output.
  • We added a status message to the result like we did with RPM 4.5
  • We also remove the column headers if no jobs are listed.
  • You can control whether RPM sends actual job results from "lpstat" using a setting in the UI. It is off by default.

Small jobs removed

The user interface lets you set a minimum size for jobs; any job that size or less is supposed to be removed. Unfortunately, we were merely leaving them in the "xfer" state. Now they are automatically removed as they were supposed to be.

Non-ASCII job names

If the job name in the control file is not ASCII or UTF-8 we attempt to use the system's native code page to translate the name to UTF-8. If that fails we'll replace non-ASCII characters with an underscore. This should not affect the job processing, and you can use data extraction to override the job name.