LPD is the print protocol utilized across the Internet for 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 that 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 primary considerations for this new LPD handling module. This page provides background on LPD and LPR.
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 program that 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, multiple data files, and combinations thereof. Some Linux clients use this as a way of sending more than one print job 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 before this.
LPD stream support
RPM supports the so-called "LPD stream" where the data size is said to be zero, which is another way of handling the "don't count the data bytes first" problem.
Introduced Capture support
We've added a "capture" feature that writes the overhead part of the LPD protocol to a file, which we can then replay. Capture will help us understand unexpected job behavior not related to the actual data. It does not (at this writing) include the job data, instead a representation which we can use to synthesize a fake job.
This post describes the capture function in detail and includes setup instructions.
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 came 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 as 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.