From: moore+@CS.CMU.EDU (Dale Moore)
Newsgroups: comp.periphs.printers
Subject: A Review of PrntSvr BSD Source Kit
Keywords: DEC, LPS20, LPS40, Print-Server
Date: 24 Jul 92 16:32:19 GMT
Article-I.D.: cs.1992Jul24.163219.103442
Organization: Carnegie Mellon University

The information below is of concern only for owners and potential
owners of DEC PrinterServer networked printers.

I recently received from Digital Equipment Corporation BB-PMKAA PrintServer
Source Kit for BSD UNIX, Version 4.0.  This kit contains sources and
documentation for the client side of communicating over the network to the DEC
PrintServer 40 (LPS40) and PrintServer 20 (LPS20).  This will allow your BSD or
SUN-OS machines to ship print requests to DEC's network printers.

I was dissappointed in the quality of the code.  Several times I found the source
code in need of repairs to work as advertised.  In other cases, although not wrong,
the source was certainly confusing and muddled.

Below is a snippet of source code that was provided...
(Yes, I know, this probably violates any and all license agreements.  If you feel
that you must, please initiate legal proceedings.)

        char * path;
...
        /* Skip leading and strip trailing "/" characters from the path */

        while ((*path == '/') && (*path != 0))
                path++;

If the first character is '/', it certainly won't be 0.  So why check for 0?

There are other cases where the code is more confusing, and occasionally wrong. 
Hostnames are treated in a case sensitive manner.  So if I would configure the
software to run on the set of machines "Apple.CS.CMU.EDU, Boy.CS.CMU.EDU",
and if gethostname() (2) returns "APPLE.CS.CMU.EDU", the machine won't be
found in the list, and the software won't start up.  Hostnames are and always
should have been case insensitive (but preserve case when possible).

The kit provides all the sources for the clients side of the printer.  But it does not
provide the sources for the server software that is downloaded at boot time.  This
is not unexpected, because the software that is downloaded includes the PostScript
Interpreter, VAXELN (DEC's Real-Time Vax Operating System), and other
tidbits.  The sources for the PostScript interpreter are probably the life blood for
Adobe.   The server images are provided in binary form only.  Most, but not all
server images are provided. The missing pieces are discussed below.

The first binary image is placed in the printer via bootp (and tftp) or via DEC's MOP
protocol.  Since the machine I was working with was an LPS40, the MOP boot was
my only option.  But the image necessary to download into the LPS40 via MOP was
not included with the source kit.

So, I had purchased the Ultrix PrintSrv supporting Host V4.0 BB-MN65C-BE, and
installed that version of the file LPS40 system boot image.  Both were labelled V4.0
so that image should work.... Right?  Wrong!  Unfortunately, that version of the
boot image was evidently not compatible  with the subsequent (secondary boot)
images that LPS40 printer slurped in from our client system.  After installing the a
different secondary boot image from the Ultrix tape, rather than the Source tape
things tended to work more as expected.

Another problem that we seem to be having is with the ARP (Address Resolution
Protcol) implementation present in the software.  In case you've been sleeping for
the last 12 years, the ARP protocol provides a mapping between network
addresses (like the TCP address 128.2.250.227) and the hardware address (the
ethernet address 08-00-2b-bf-dd-ec).  The arp request packet is broadcast
on the net 
	Hi I'm looking for 128.2.123.45,
	and I'm 08-00-2b-00-00-01 netaddress 128.2.123.46.
The reply from 128.2.123.45 is directed  (not broadcast) back to requestor.
	Hi there 128.2.123.46 (08-00-2b-00-00-01).
	I'm 128.2.123.45 and my net address is (08-00-2b-00-02-aa)

The printer network software maintains a cache or table of the mappings between
network address and hardware address.  Now, when you do a "netstat" on our
printers, you'll see that the arp table is filled to the brim!   I suspect that the arp
implementation on the printers are trying to record the mapping in each and every
broadcast arp that it hears on the net.  A better implementation of arp will only
record in its arp-cache table those entries that it is truly interested in.  It should be
truly interested in the mappings that it already has in its table, and those that it is
actively seeking.  All others entries should be dropped.  This will keep the size of
the arp table small, and reduce the amount of updating in this table.   This is what
is recommended in the ARP specification.  Unfortunately, it appears that DEC
didn't follow this in their implementation.

On our cables we typically have 2 to 7 broadcast arps per second.  We have over
5000 machines on our  network.  Most of these machines  will never directly
communicate with this printer.  After all, why should the printer be intersted in a
terminal server? The terminal server will never connect  to my printer, and my
printer will never connect to my terminal server.

Although I find the quality of the software poor, the quality of the documentation
is better.  Included in the source kit are PostScript versions of the documentation.
The documentation covers the Installation Guide, Users Guide and Release Notes
and a specification for the protocol between the client and printer.  Obsolete
versions of the protocol document can be found on the
wrl-techreports@wrl.dec.com mail file server.

As is the case with most DEC documentation, the documentation and installation
guide assume someone who is almost computer illiterate.   Although complete and
relatively well organized, it is sometimes difficult to find the appropriate tidbit of
information amongst all the fluff.  Sometimes this can be a delightful change from
typically terse Unix man page.

In general, I'm disappointed in this product.  Unless you already have a
DEC LPS20 or DEC LPS40 printer, and find that you seriously need the
functionality or service offered by this software,  you might consider waiting
a few years to see if anything better comes out of DEC.

Dale Moore 
Dale.Moore@CMU.EDU
Senior Research Systems Programmer
School of Computer Science
Carnegie Mellon University

All opinions expressed above are mine and do not necessarily represent
the true state of the world.
The information above has been or will be forwarded to DEC Software
Performance Report center.  It is included in this forum only to inform
others of potential problems.
Newsgroups: comp.periphs.printers