From: levine@regent.enet.dec.com (Rick LeVine)
Newsgroups: comp.periphs.printers
Subject: TCP/IP and network printers. RE: comp.periphs.printers 4697
Date: 5 Oct 92 20:18:23 GMT
Article-I.D.: nntpd.1992Oct5.192134.2645
Organization: Digital Equipment Corporation

-------------------------------------------------------------------------------
REPOSTING: Original followup posting failed for no apparent reason.
           This is in reply to posting 4697 in which Sam (shm@syl.nj.nec.com
           Shailendra Majmundar) asked about TCP/IP network printing 
           architectures

In response to comp.periphs.printers article 4967, posted by Shailendra 
Majmundar, shm@syl.nj.nec.com, I would first like to identify myself as
a network printing product developer. Specifically, I work in Digital 
Equipment Corporation's network printing department. We have been selling and
developing network printing solutions since the mid 1980's, and we have
given a lot of thought to these issues.

I will be citing examples of a good network printing architecture below.

#When people say a printer supports TCP/IP (or complain about the
#lack of support), what do they really mean?  Is it that the
#printer has a full tcp/ip stack running on it along with some
#application on top of it?  Assuming that the printer is stand-alone
#(ie., it is not attached to a computer), what does it take to
#support such a set up?  Do the printers have a spooling space
#(which I guess, implies a hard disk) where requests from various
#network clients get queued and later get printed, or do they
#accept only one request at a time?
#

Good question. Many vendors in this space have created solutions
that are essentially a UNIX workstation hidden inside the printer, or
a limited subset of standard UNIX workstation functionality in a small 
external box.

Of course, those solutions are functionally no different than buying a 
workstation or server box and attaching a printer.

Clearly, such a hybrid solution would act like a tcpip host, would
respond to ping, lpr, finger, telnet, etc. This is a workable solution.
But this is not a network printing architecture.

#I guess, I am really wondering about the software architecture
#on the printer and the method(s) of communicating with it.
#

-architecture-

This is the heart of the matter. If you choose the above solution, in which the
printer has an on-board workstation and the workstation accepts spooling
commands via lpd or telnet, then you have not got a network printing 
architecture; what you have is a Value-Added-Reseller solution made of 
components from many vendors.

In designing a network printing architecture, both the software architecture 
and the hardware architecture are equal in importance.

SOFTWARE:

A network printing architecture requires a view of the big picture;
connectivity to TCP/IP and other networks, high reliability, high data
throughput, management tools.


-protocols-

Many network printing vendors offer solutions based entirely on telnet and/or 
lpd connectivity on tcp/ip networks. These are traditional UNIX ways of moving 
data on tcp/ip networks, but they are not necessarily the best way to address 
a shared network printer.

First, lets talk about performance. Using standard lpd on tcpip, the printer
(or hidden-workstation if you will) has to parse every byte of the incoming
data stream, looking for control characters. Networked printers, especially
PostScript printers, can expect to get huge files. A vendor whose network
printing architecture supported a dual channel (FTP-like) print protocol
would have clear performance advantages. (In point of fact, Digital's CPAP
network printing protocol does exactly that). 

The obvious advantage that comes to mind here is SPEED. If you have ever pushed
big files around with FTP you know how fast a dual channel protocol can be.
The real reason it works so well is that THE INCOMING DATA DOES NOT NEED TO BE
PARSED in order to find the end of file, etc. Think about the extra work
required to parse every byte of an incoming 5 megabyte file looking for EOF and
THEN having PostScript re-parse it as it interprets the page info.

Performance is NOT the only reason to choose such a robust protocol,
though. A major factor in driving this choice was CONTROL CHARACTER
ALIASING... if you are reading in an image file under any of the other
print protocols and the bits in the image sequence happen to alias
a CONTROL D, 99% of the time your job will abort.(Because the printer
SAW a CONTROL D). Dual channel means that aliasing is never a problem
and no fancy workarounds are needed.

-spooling-

As I said above, many other network printing solutions copy the print file
wholesale to a local hard disk in the printer. For the most part they do this
because they are emulating a remote lpd "rp=" printer. 

To put this in more familiar terms, if you are using NFS and have a remote
disk mounted, you are accessing files via the network, without copying
them to your local disk. (In fact, you do not even need a local disk at all.)

A network printer with an appropriately thought-out protocol should have the
same degree of transparent access to files anywhere on the network without
having to duplicate them locally. The printer should be able to get what it
needs, on demand, from any host which has a pending print job. That is, in
a general sense, what Digital's CPAP protocol provides.

An interesting side effect and benefit of this architectural choice is that the
print client process local to you always knows how much of the file has been
sent at any given time. The file never appears to have been completely
printed until it is in fact really done.

-queueing-

The PrintServer family enforces fair round robin queueing from direct printing
clients on your network. What that means in simple terms is that jobs print
in the order they were submitted, regardless of where they were submitted
from, or what operating system. The print protocol includes a handshaking 
sequence, so the printer tells the submitting client process when it is ready
to accept each job. 

-management-

Being able to print to a remote printer is a partial solution at best. We 
have found that people expect to manage their network resources remotely, 
using the network itself. Over the years, we have developed a number of tools 
and features that make this a reality:

	- notification of job completion on YOUR workstation or terminal
	- notification of problems (paper out)  on YOUR workstation or terminal
	- system manager tools that allow you to MANAGE THE PRINTER REMOTELY
	- accounting software so you know who is using this resource
	- access control software so you can limit access if you wish
	- soft font (remote) loading capability

We have used the CPAP protocol to create remote management utilities ,
even a REALTIME PRINTER MONITOR that tells you when a tray is removed
or a door is opened, even if you are in Boise and the printer is in
Georgia somewhere. 

-remote printer upgrades-

Management also includes UPGRADING THE PRINTER. Digital's PrintServer printers
are upgraded remotely with software. No walking around, plugging roms or
floppies into them. You can manage and upgrade every PrintServer printer on 
your network without leaving your office.

HARDWARE:

We have talked about software features and architecture, but the design of
the hardware is equally important. Many vendors offer solutions that use
general purpose workstation or PC boards. These work as short term solutions
but they were not designed with the daily workload of a network printer in
mind.

-performance and bandwidth-

A network printer needs lots of on-board memory, a bus that can move data
quickly and with high bandwidth, and other printer-specific features
such as caching hardware and ccitt decompression hardware. 

Many vendors would have you measure network printer performance in terms of 
MIPS, but that is an arbitrary measure and may not have much bearing on
how many pages per minute the printer will actually produce under heavy loads.

For our PrintServer printers we chose a robust CISC cpu over a purportedly 
"faster" RISC cpu. This allows for excellent realtime event handling plus
the hardware-enhanced capability of moving bits to the image buffer very fast.

-intelligence rather than brute force-

Our PrintServer family also has on-board CCITT decompression; it allows for
multi-megabyte-per-page image printing at 20 PPM on the PrintServer 20,
and close to 30 PPM on the new PrintServer 32. In both cases this was
accomplished with an elegant on-board hardware architecture, not by the
addition of a faster CPU. 

-reliability-

One of the questions you raised was whether some of these solutions require
an on-board hard disk in the printer to accept standard lpd spooling
requests. Many competitive solutions have found it necessary to incorporate
a hard disk drive into the printer. We considered this as an option, but we
found that the addition of a hard disk drive adversely effected the printer's
overall reliability.

Here are some simple reasons why a hard disk is not necessarily a good thing
to have inside a network printer:

	-Hard disk drives contain many moving parts, bearings, heads, motors
	 and they are statistically more likely to fail than solid state
	 memory-based systems.

	-Hard disks add heat to the overall heat output of the printer's 
	 internal components. This requires more cooling capability
	 (more or larger fans) or the overall heat added can cause components
	 other than the hard disk to fail as well.

	-The hard disks themselves and the additional cooling add to the
	 load on the internal power supply.

	-All of this added complexity makes hardware failure more likley,
	 plus it increases the diagnostic and repair time for the unit.

	-Hard disks require LOCAL MANAGEMENT, plus they usually require
	 a local way to install software.Usually a floppy drive. Which
	 adds heat, draws power, increases complexity further. And you have
	 to walk over to it and feed it floppies.

	-Hard disk drives and floppy drives both require cooler, gentler
	 environments than solid state devices. Hard drives in particular
	 can fail due to external vibration or shock. Data, including your
	 print-job-in-progress, can be lost permanently.

-the engine-

These printers print on a wide variety of paper sizes, including
11 x 17 (B) size, and the popular european sizes. Some models can print
as much as 150,000 pages per month, month after month. All are user-installable
and easy to maintain.

-lessons learned over a decade-

We have been doing this class of work for almost a decade now, and we have 
learned a great deal from customers, many of them with needs similar to yours.
Everything I have described above is available, today. If you want to ask me
more questions, I would be glad to dialogue with you on this subject. 

#Can someone enlighten me?  E-mail is welcome, but I'm sure many
#people will be interested on this topic, so posting on the net
#is preferred.  It would be nice if this leads to a discussion
#on the pros/cons of various architectures.
#

Keep asking questions. You are being a wise consumer, and no doubt this note 
will strike up some lively conversation.

Regards,
------------------------------------------------------------------------------- 
Rick LeVine				levine@regent.enet.dec.com
Senior Engineer
PrintServer Systems Engineering
Digital Equipment Corporation
Westford, MA 
Newsgroups: comp.periphs.printers