Networking Updates in RPM 6.2

Networking is a core area of RPM Remote Print Manager® ("RPM") and something we put a lot of focus on.

In this release, we introduced a new "LPD" module. We completely rewrote the way we handle incoming LPD requests and how we created the jobs. The page to the left of this includes the highlights and we will document the new functionality thoroughly.

However, we did a lot in the networking part of the system outside of LPD, which we describe here.

New network print actions

RPM supports two network print actions: LPR and IP. That is, we receive, and we also send out. In this release we replaced the old implementations for these outputs with all new code. Our goal was code that responded quickly and yet let us know of potential problems. In testing, we have sent tens of thousands of jobs through those actions. We have tested this with RPM in our local network and with our various printers.

This code has been available for several beta releases. For a very brief window of time the new Print LPR was sending jobs to the same host they came from, which of course we fixed immediately

Network distance relief

A client was experiencing unexpected problems with jobs sent from a considerable networking “distance”. Some jobs randomly seemed to never complete. It turns out that their client system was sending “write” and “close” events at the same time. We had never seen this but found a way to account for it. This seemed to solve their problem.

Telnet issues

  • If you ran RPM with a clean database, the telnet manager would fault because it’s next job ID was not specified as expected. This is fixed.
  • If the job name template was blank, incoming jobs would produce a fault. The telnet manager now provides a default template for creating a name if none is specified. This has also been fixed in the UI.
  • When RPM starts up it will now look for empty data files and abandoned data files for prior telnet sessions

Other issues

  • The socket for “lpstat” commands is now shut down proactively which helps keep the LPD jobs processing at a steady rate
  • Eliminated a frequent call to check on listening ports, which occasionally fails for unknown reasons and results in RPM reporting that it’s own path is using the port. This required a system reboot to fix.