A.P. Lawrence

Comments /SCOFAQ/scotec7.html


Sat Apr 22 22:39:15 2006 Using a named pipe for remote printing  anonymous

From fthynne@elmplace.co.uk

I needed to migrate from serial printers to network printers using (D-Link
and Netgear) print server devices. Unlike a Unix system, those devices have
no understanding of printer capabilities. I therefore needed to retain the
interface mechanisms used with local printers. I fell upon your suggestion
of diverting printing to a remote printer using a named pipe and a perpetual
script with enthusiasm, and at first it appeared to work brilliantly. However,
disappointment set in when garbled print came out of busy printers. This
is, I think, caused by a rapid succession of lp jobs for the same printer
that write concurrently to the same named pipe. It seems that the lp system
relies on the ability of a process to lock a tty for exclusive writing,
and to wait if it finds a locked tty; I am not aware of a similar feature
for named pipes. The remedy seems to be to amend the interface scripts to
invoke the remote print instead, as I believe you and others have suggested
elsewhere, and abandon the neat but, it seems, flawed approach of using
a named pipe.


Sun Apr 23 11:11:08 2006   TonyLawrence





The lp system gives a job exclusive use of the pipe until the job is finished,
so there is no overlap.



On a very busy system, it's possible for the lp system to
send new data to the pipe before your reader process has sent it to
the print server. You could implement a cooperative locking system
to prevent that, but a small sleep at the end of the interface script
will probably work.


Sun Apr 23 23:20:25 2006   BigDumbDInosaur

I doubt that either the lp subsystem or the named pipe are to blame. As
Tony said, the lp subsystem processes one print job per printer at any given
time -- there is no concurrent output. Therefore, as long as the data flow
to the named pipe is coming only from lp, you should not be experiencing
intermixing. The pipe itself is a sequential data conduit. Bytes will be
read from the output end in the exact order in which they were written to
the input end -- you can count on it!

There are several possiblities that
come to mind, but not necessarily applicable to your situation, since I
don't have the system in front of me. One is that TCP flow control is not
being correctly implemented at the receiving end. Are you sure the printer
server device attached to the printer correctly implements the ACK/BUSY
sequence on the printer side? Also, when the printer asserts BUSY (which
you can simulate by taking it off-line), does the printer server correctly
do a TCP NACK, which should stall data flow (check that with netstat)? Is
there more than one process writing to the named pipe, causing data to get
intermixed and confusing the printer? lp won't do this but something else
could without you knowing it. You didn't say exactly how you are reading
out of the pipe and sending it onward to the printer. If using netcat, are
you sure that only one instance of netcat is running and connected to the
print server?

Oh, one more thing. Junk that Netgear stuff. Those things,
in my opinion, make far better door stops than network printer interfaces.
The best external print servers are the HP JetDirect 300 models. I have
some around here I bought in the mid-1990's that are still working like
a charm.




Sun Apr 23 23:31:50 2006   TonyLawrence

BDD makes good points, but I still see the possibility of a race condition
here on the reader side. BDD's advice should certainly not be ignored but
if the race does exist, it won't be fixed this way.



Do check the netgear with the printer off-line: I've definitely seen
that problem with these cheap units.


Mon Apr 24 03:52:49 2006   BigDumbDinosaur

The race condition that Tony is speaking of will probably come at the end
of the run, when all bytes have been read from the named pipe but, for whatever
reason, the last buffer full has not been flushed to the target printer
(a network propagation delay could account for this behavior, but on a LAN,
a temporarily full buffer at the printer end -- or the printer being off-line
-- is most likely the cause).

In any case, as soon as lpcat (the part
of the lp subsystem that actually drives the printer) finishes with the
first job, lpsched will spawn a new instance of lpcat to start the next
job for that printer, stuffing a new byte stream into the named pipe. The
elapsed time involved between the end of the first job and the start of
the second could be very short -- a few milliseconds if the server isn't
very busy. Meanwhile, assuming that all data from the previous job has not
been flushed, there will still be a TCP connection opened to the print server
for that job, yet the new job may have set up another connection. This sequence
of events, which is permissble under the rules that govern TCP (in theory,
any number of clients could set up a TCP link to a server, which is how
a website like this one can handle many simultaneous hits), establishes
the race condition. Now the question is, when the data stream stall clears,
which connection -- that is to say, which print job -- will get to go first?
If it's the old job you're okay. If the new one gets in there first (due
to kernel scheduling, perhaps), you have out of order data, and garbage
on the paper.

Again, since I don't know how you implemented this setup,
I can only speak in generalities. What you need to do is to insert something
at the end of your code that verifies that all data has been flushed from
the first job before processing the next one. In other words, you need to
absolutely guarantee that only one TCP path to the target print server can
be created at a time. Hope that gives you a few ideas.


Thu May 11 02:26:26 2006 network printers, interfaces, and IP addresses  TheMonster

I have a quibble with the techniques shown here for printing to network
printers. You show the commands with actual IP addresses as the target.
Unfortunately, those addresses change from time to time. When that happens,
it can be a real pain to track down every place that the old address is
used. So I recommend always putting the printer IP address and name in /etc/hosts,
and using the hostname of the printer instead of the IP in your scripts.
The IP ought to be documented in hosts anyway, unless you're using DNS,
in which case it ought to be there instead.

If you build an interface that uses `basename $0` as the network address,
it will automatically take the name of the printer.

That way, when you realize that the IP scheme you're using on your local
network includes public IPs of an Air Force base, and you want to change
it before you install DSL, so that you can avoid being arrested for trying
to hack into DoD assets (true story for one of our customers, inherited
from a smaller company we bought out several years ago.), you just edit
the hosts file, and you're done.


Thu May 11 10:00:41 2006   TonyLawrence

True. I tend to show IP addresses here to make it plain that they ARE IP
addresses.


Add your comments