How Telnet printing works in RPM

Introduction to Telnet Printing

If you have ever noticed a printer supporting TCP port 9100, that’s the telnet protocol. It’s sometimes called the raw socket protocol. We support this in RPM Remote Print Manager® (“RPM”) as an additional print protocol; we don’t enable it by default but it’s part of the product nonetheless.

You may have heard of a different telnet protocol used to log into a remote computer and enjoy a command line environment. These days, telnet is usually phased out in favor of a secure login such as ssh. In fact, we use the command line program putty to log into Ubuntu hosts on our own internal network.

With telnet printing, your application opens up a connection to port 9100 on your print server and sends the data you need to print. Then close the connection; it’s basically that simple.

How RPM supports telnet printing

RPM creates an LPD handling port when you install. This is because an LPD print request includes a queue name, so RPM knows what queue to send jobs to.

Telnet does not include a queue name, so RPM waits for you to create a telnet handling port so you can configure a queue name for that port.

In the user interface go to Configure / Port Settings:

Note that there is no telnet port in the active ports list in this form. Click “Select Port Type to Add” and select “Telnet”:

Once you have selected “Telnet” then click the “Add Port” button for the Telnet setup form:

If you want to use a queue you’ve already created, click the list next to “Queue” so you can select it. If you want to create a new queue and use that instead, click the “Add Queue” button.

Here I’ve clicked the queue list:

If I click OK to close the telnet setup form I should be on my way to receiving telnet printing.

Here is a subset of jobs I sent using telnet printing and the settings above:

Creating multiple ports

It’s simple to create multiple telnet listening ports. Typically you might start with port 9100 as shown in the telnet setup form, but I’ve often created ten or a dozen ports, for instance, 9100 through 9110. All are active and all have their distinct setup. You might select different queues for each of these ports.

Print pages when idle

By default, RPM will see the job as complete when the client program closes the port. If you want a different behavior, select “Print pages when idle”. This way the client program can leave the port open and just stop sending data for a moment to signal the end of the print job.

Telnet user

Every RPM print job has a user. This is part of the LPD print protocol. We’ve selected “Telnet” as the default telnet print user but you can set that to anything you want.

Job name

The job name is also part of the LPD print protocol. If you look at the jobs panel for an RPM queue, the job name is prominently displayed.

The telnet form lets you create a job name which RPM will construct on the fly when a job arrives.

Recent improvements in telnet printing

Prior to RPM 6.2 we decoupled receiving the jobs from creating the jobs. In the past, we could reliably transmit close to 1,000 jobs before Windows stopped allowing the connection. When we next tried, the number would be greatly reduced, and so on.

I believe this had something to do with TCP/IP being part of an emulation layer in Windows which simply ran out of buffer space.

It seems that the delay RPM incurred from making a couple of round trips to the database escalated the problem. However, if you were sending jobs at the rate of several hundred per hour, I doubt you would ever notice this issue.

Now that we spool the jobs and let RPM create them in the database out of band, we have had far greater success receiving large numbers of telnet print jobs in a short time.