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 it's 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 in one of the four methods described in the following sections.
The printer can be physically cabled to the PC running the Network OS. 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.
It is possible to run a print server program on a cheap PC that is located next to the printer and plugged into it via parallel cable. 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 fileserver, where jobs are controlled.
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. 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.
The HP JetDirect Internal is the best known printserver of this type. It is inserted into a slot in the printer case, and it works identically to the external JetDirect units.
Printspooling 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 on a queue so that one can be printed after the other.
Printspooling can be implemented at one of three locations
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 print server 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.
The printserver. If each printer on the network is allocated their own combination print spooler-printserver, jobs can stack at the printer. Many of the larger printers with internal printservers have internal hard disks for this purpose. Although this enables basic job management, it still restricts the ability to move jobs from one printer to another.
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 4 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.
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.
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 requisition smaller printers that are more convenient for that quick print job. The administrator may end up with a datacenter 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 is that scattering printers through the organization makes it difficult to utilize the 3 possible parallel ports on the fileserver due to parallel port distance limitations. Although high-speed serial ports may extend the distance, not many printers have good serial ports on them. This is where the hardware network print server 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.00. 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 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.
Although several proprietary network printing protocols such as Banyan Vines and NetWare, are tied to proprietary network 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.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the
before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.
Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру