Ref: 11640034
Title: How Data is Sent Between a CS/210 and a Print Spooler
date: 6/28/89

Copyright 3Com Corporation, 1991.  All rights reserved.

This article describes how a CS/210 handles buffering of data
sent to a print spooler.  For this discussion, the software used
was TCP/IP version 20100 on the CS/210 and UNIX spooling through
a CS/210 to a printer.

When the UNIX spooler reaches the end-of-file marker it closes
the TCP network connection.  The Comm Server has data buffered
for the printer, which it is sending as fast as flow control will
allow, but it does not have a TCP connection.  At the close of
the connection, the Comm Server starts a countdown timer.  When
this timer expires, all pending buffers are freed.  If all the
data has not already been sent from the Comm Server's buffer to
the printer, it will be lost.  The Comm Server must do this to
prevent ports from becoming deadlocked.

While the timer is counting down (that is, while there is no TCP
connection), any connection request to the printer port will be
rejected since the buffers and the port are still in use.

To prevent spooled data from being lost from the buffer, you have
two options:  to extend the duration of the disconnect timer and
hope that the printer can take all the buffered data before the
timer expires, or to ensure that the data in the buffer at the
time of disconnection is expendable.

With the first option, using an extended disconnect timer, you
are in a race with the clock to ensure that all the data gets
from the Comm Server's buffers to the printer.  Also, the printer
is unnecessarily tied up after the successful completion of a
print job.

Using an extended disconnect timer, physical problems (such as
paper out or the printer being jammed or offline) that occur near
the end of the print job will likely cause data loss.  For
example, if the printer runs out of paper on the last page, the
printer will flow-control the Comm Server, but the Comm Server
already disconnected from the host after it reached the end of
the print job.  The last page of data is in the Comm Server's
buffer.  By the time the user picks up his printout, the extended
disconnect timer has already expired so the last few Kbytes of
data have been lost.

The second option, to pad the end of each file with data that can
be lost, is better.  Most printers ignore the ASCII null
character (code 0).  Thus the UNIX spooler can send nulls at the
end of each spooled print job.  Then, after the connection is
broken the only data in the Comm Server's buffer will be
expendable null characters.


Considerations for Padding Files

The padding characters must be sent before the TCP disconnection
of the UNIX host from the listener port.  When sending more than
one file to the spooler, you can choose to make the connection,
send all the files, send the padding, then disconnect.  Or, for
each file separately, you can make the connection, send the file,
send padding, then disconnect.

The first option, sending all the files together with one set of
padding after, requires the spooler to discern that all four
files are destined for the same printer and to spool all four
files together as a single print job.  Although harder to
implement than the second option, the first option is the most
efficient solution and should be preferred.

The amount of null padding needed at the end of each print job
varies, depending on the software revision and the hardware
platform.  The determining factor is the maximum amount of data
that the hardware and software will buffer.  In TCP/IP this is
referred to as the window size.  For the specific case of the
CS/210 running SW/200 TCP revision 20100, the maximum window size
is 4096 bytes (4K).  To ensure that only nulls are in the Comm
Server's buffer after each print job, an additional 4097 bytes
(max-window-size + 1) of null padding should be sent.

When adding padding to a file, there is a fixed overhead for each
job that is spooled.  However, if the constant max-window-size +
1 byte of padding follows each print job then it is safe to
SYSGEN the disconnect timer as low as possible, because we know
that only junk data is in the last buffer and we don't need this
data sent to the printer.  By setting the disconnect timer low we
can try to throw away the last full buffer (which only has nulls
in it) as soon as possible after the disconnection.  This will
mean that the printer will, hopefully, never have to see a full
buffer of nulls.  Also, the printer port is available for another
connection more quickly after the print spooler initiates the
disconnection sequence.


Troubleshooting

To fully troubleshoot a configuration you would need an Ethernet
scope to observe the window size negotiation between the Comm
Server and the host and an async scope between the printer and
the Comm Server to observe the nulls that are at the end of the
print job.  Note that the TCP/IP window size negotiation is not
related to any of the buffer parameters seen at the user
interface.  With our Comm Servers the maximum window size can be
seen in the first acknowledge from the Comm Server to the host.
Under the TCP protocol window size is piggybacked to acknowledge
packets whenever possible.
