How Telnet printing works in RPM

Introduction to Telnet or Raw 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 or raw printing. RPM Remote Print Manager® (“RPM”) supports raw printing as an option; it's not switched on by default, but it is simple to configure and comes standard with the product.

What is the difference between Raw and LPR printing?

With raw printing or telnet printing, the client sends the actual data that is intended to go directly to the printer, typically in the printer language.

With LPR printing, the client sends commands, and RPM responds. The data meant for the printer comes with one of those commands. The critical difference is that RPM learns quite a bit about the print job with LPR printing, which is not part of telnet printing.

How is this different from regular telnet?

You may have heard of a different telnet protocol used to log into a remote computer and use a command-line environment. These days, telnet is usually phased out in favor of a secure login such as ssh. For instance, we use a secure login with the Linux hosts in our network.

What port does telnet use?

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 link; it’s that simple.

This chart lists the ports for the protocols we're talking about:

How RPM supports telnet printing

RPM automatically creates an LPD handling port when you install it. Note that 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 chosen “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'm ready to receive telnet printing.

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

Creating multiple ports

With RPM, you can create as many telnet listening ports as you need. 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 or the same queue for all the ports. It's up to you.

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 stop sending data for a moment to signal the end of the print job.

Telnet user

Every RPM print job has a user. The LPD print protocol requires a user name. 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 that RPM will construct on the fly when a job arrives.

Recent improvements in telnet printing

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

I believe this had something to do with TCP/IP being part of an emulation layer in Windows which 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.