laser-lovers@uw-beaver (08/24/85)
From: imagen!geof@su-shasta.arpa
Since you asked....I wrote the TCP on the Imagen. It only accepts one
connection at a time. The printer is able to begin processing the next
job before the current job is finished, so it is a bad idea to have the
host wait around until the accounting information is returned. One day
we'll have a new, faster, multi-connection TCP for the printer, and we
can hack this extra feature together.
Actually, I don't think that the host that sent the job is necessarily
the right place to send the accounting information. It should really be
sent to a host that has a trusted, reliable and private accounting server
on it. We will eventually provide an adequately secure method of getting
accounting info out of the printer, and preventing unauthorized users from
using it. I can't say when that will happen, though.
In the meantime, release 2.2 of the printer software contains an
implementation of a simpler (and less secure) accounting protocol, that
will eventually be replaced (or joined) by a better one. In our usual
optimistic style, the protocol is named "accounting1." The printer is
configured with the identities of a number of accounting hosts (host names
and port numbers). After each print job finishes, the printer formats a
UDP packet containing:
A nonce identifier (a number that is unlikely to be reused).
The source internet address of the job's sender.
The number of pages actually printed.
The first 256 bytes of the job.
This packet is sent to each accounting host on the list. The protocol
operates in reliable and unreliable modes (a configured setting). In
unreliable mode, the printer sends the UDP packet to each host on the list
and continues printing. The packet is not retransmitted. If there are
enough hosts in the list, the likelihood that all will miss the packet is
small. In reliable mode, the printer sends the packet to all the accounting
servers, and retransmits it until one server sends back a response. In the
meantime, no new print jobs are processed. The main difference between the
two modes (assuming multiple accounting servers) is when all accounting
servers are down or inaccessible to the printer. In reliable mode, the
printer stops printing. In unreliable mode, it continues to print, but
accounting information is lost.
The assumption is that the first 256 bytes of the job are enough to identify
who should be billed for it. This can be guaranteed by modifying spoolers
to prefix every job with a small header:
@document( SpoolerKey ..., BillTo name )
The printer will ignore this header except to print the BillTo entry
on the header page. The "spoolerkey" entry is a special new header option
that is a noop, but doesn't register on the job's header page. The idea
is to put a secret password for each official spooler in this entry. This
makes it easier to spot someone using an "unauthorized" server, and to
find them from the source internet address that is reported in the accounting
packet.
The actual contents of the special job header are, of course, up to the
system administrator. Anything can be included -- the number of bytes
of data to be sent, whether the job is impress or diablo format, etc..
The accounting servers are quite simple, they just receive a packet,
dump its contents into a file, and loop (in reliable mode, they also ack the
packet by sending a copy of it back to the printer). Every so often,
the system administrator collects all the accounting logs on one machine
and runs a merge/sort pass on them, using the nonce identifier for each
entry as a sort key. Then duplicate entries are eliminated and the merged
log can be resorted (or otherwise processed) to produce a full accounting
summary for billing purposes. On unix, the entire merge phase can be handled
by a single line command of the form:
sort logfiles... | uniq | awk -f genreport.awkscript
(assuming that log entries are each on one (ascii) line).
- Geof Cooper
Imagen