Home > Articles > Operating Systems, Server

  • Print
  • + Share This

Network Printing Basics

The most common network printing implementation is a printserver accepting print jobs from clients tied to the server via a network cable.


The term printserver is one of those networking terms, like packet, that has been carelessly tossed around until its meaning has become somewhat confusing and blurred. To be specific, a printserver is simply a program that arbitrates print data from multiple clients for a single printer. Printservers can be implemented by one of four methods described in the following sections.

Printserver on a Fileserver

A printer can be physically cabled to the PC running the NOS (Figure 8.1). Print jobs are submitted by clients to the printserver software on the fileserver, which sends them down the parallel or serial cable to the printer. The printer must be physically close to the fileserver. This kind of printserving is popular in smaller workgroup networks in smaller offices.

Figure 8.1 
Printserver on a fileserver

Printserver on a Separate PC

It is possible to run a printserver program on a cheap PC that is located next to the printer and plugged into it via parallel cable (Figure 8.2). This program simply acts as a pass-through program, taking network packets from the network interface and passing them to the printer. This kind of server doesn't allow any manipulation of print jobs; jobs usually come from a central file server, where jobs are controlled.

Figure 8.2 
Printserver on a separate PC

Printserver on a Separate Hardware Box

A printserver on a separate hardware box is exemplified by network devices such as the Intel Netport, the HP JetDirect Ex, the Osicom/DPI NETPrint, and the Lexmark MarkNet (Figure 8.3). Basically, these are plastic boxes with an Ethernet connection on one side and a parallel port on the other. Like a printserver on a PC, these devices don't allow remote job manipulation and merely pass packets from the network down the parallel port to the printer.

Figure 8.3 
Printserver on a hardware box

Printserver in the Printer

The HP JetDirect Internal is the best known printserver of this type (Figure 8.4). It is inserted into a slot in the printer case, and it works identically to the external JetDirect units.

Figure 8.4 
Printserver in the printer

Print Spools

Print spooling is an integral part of network printing. Since the PC can spit out data much faster than the printer can accept it, the data must be buffered in a spool at some location. In addition, because many clients share printers, when clients send print jobs at the same time, jobs must be placed in a queue so that one can be printed after the other.

Logical Location of the Print Spool

Print spooling can be implemented at one of three locations (see Figure 8.5).

  1. The client. Clients can be required to spool their own print jobs on their own disks. For example, when a Windows client application generates a print job, the job must be placed on the local client's hard drive. Once the remote printserver is free to accept the job, it signals the client to start sending the job a bit at a time. Client spooling is popular in peer-to-peer networks with no defined central fileserver. However, it is impossible for a central administrator to perform advanced print job management tasks, such as moving a particular print job ahead of another or deleting jobs.

  2. The printserver. If each printer on the network is allocated its own combination print spooler–printserver, jobs can stack at the printer. Many of the larger printers with internal printservers have internal hard drives for this purpose. Although this enables basic job management, it still restricts the ability to move jobs from one printer to another.

  3. A central print spooler on a fileserver. Print jobs are received from all clients on the network in the spool and then dispatched to the appropriate printer. This scheme is the best for locations with several busy printers and many clients. Administration is extremely simple because all print jobs are spooled on a central server, which is particularly important in bigger organizations. Many large organizations have standardized on PostScript printing for all printing; in the event that a particular printer fails and is offline, incoming PostScript print jobs can be rerouted automatically to another printer. Since all printers and clients are using PostScript, clients don't need to be reconfigured when this happens. Print jobs appear the same whether printed on a four-page-per-minute NEC Silentwriter 95 or a 24-page-per-minute HP LaserJet 5SiMX if both printers are defined in the client as PostScript printers.

Figure 8.5 
Print spool locations

FreeBSD is an excellent platform to implement centralized printserving and print spooling. The rest of this chapter concentrates on the centralized print spooler model. Note that PostScript printing is not a requirement for this model—the HPPCL protocol can be the standard print protocol as well. For transparent printing between printers with HPPCL, however, the printer models must be similar.

Physical Location of the Print Spool

In some companies, the central fileserver is often placed in a closet, locked away. Printers, on the other hand, are best located in high-traffic areas for ease of use. Network printing works best when the printers are evenly distributed throughout the organization. Attempting to place all the major printers in one location, as technically advantageous as it may seem, merely provokes users to request smaller printers that are more convenient for a quick print job. The administrator may end up with a data center full of nice, expensive printers that are never used while the smaller personal laser printers scattered throughout the plant bear most of the printing load.

The big problem with this situation is that scattering printers throughout the organization makes it difficult to use the three possible parallel ports on the fileserver due to parallel port distance limitations. Although high-speed serial ports may extend that distance, not many printers have good serial ports on them. This is where the hardware network printserver devices can come into play. I prefer using these devices because they are much cheaper and more reliable than a standalone PC running printserver software. For example, Castelle (http://www.castelle.com/) sells the LANpress 1P/10BT printserver for about $170. Using these devices, a FreeBSD UNIX server can have dozens of print spools accepting print jobs and then route them back out over the network to these remote printserver boxes. If these kinds of hardware servers are used, they must support the Line Printer Daemon (LPD) print protocol.

With a scheme like this, it is important to have enough disk space on the spool to handle the print jobs. A single large PowerPoint presentation PostScript print job containing many graphics may be over 100MB. When many such jobs stack up in the print spool waiting to print, the print spooler should have several gigabytes of free disk space available.

Network Printing to Remote Spools

Although several proprietary network printing protocols, such as Banyan Vines and NetWare, are tied to proprietary protocols, FreeBSD UNIX can use two TCP/IP network printing protocols to print to remote print spools. The two print protocols available on TCP/IP with FreeBSD are the open LPD protocol and the NetBIOS-over-TCP/IP Server Messaging Block (SMB) print protocol first defined by Intel and Microsoft and later used by IBM and Microsoft.

The LPD protocol is defined in RFC1179. This network protocol is the standard print protocol used on all UNIX systems. LPD client implementations exist for all Windows operating systems and DOS. Microsoft has written LPD for the Windows NT versions; the other Windows operating system implementations are provided by third parties.

The Microsoft Networking network protocol that runs on top of SMB can use NetBIOS over TCP/IP, as defined in RFC1001 and RFC1002. This protocol has a specification for printing that is the same print protocol used to send print jobs to NT server by Microsoft clients. To implement this protocol on FreeBSD requires the installation of the Samba client suite of programs discussed in Chapter 7.


  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.