Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.berkeley.edu.BERKELEY.EDU
Path: utzoo!decvax!decwrl!ucbvax.berkeley.edu!laser-lovers
From: laser-lovers@ucbvax.berkeley.edu.UUCP
Newsgroups: mod.computers.laser-printers
Subject: Re: Losing files on Imagen due to Losing spooler on Unix
Message-ID: <8601240344.AA15293@decwrl.DEC.COM>
Date: Thu, 23-Jan-86 21:13:13 EST
Article-I.D.: decwrl.8601240344.AA15293
Posted: Thu Jan 23 21:13:13 1986
Date-Received: Sat, 25-Jan-86 05:18:48 EST
Sender: daemon@ucbvax.berkeley.edu.BERKELEY.EDU
Reply-To: imagen!geof@decwrl
Organization: The ARPA Internet
Lines: 81
Approved: laser-lovers@washington.arpa


 >      We have a Canon Imagen 8/300 laser printer hooked up to SUN-2's
 >      via Ethernet.  We use these to print out graphs and binary images.
 >      (halftones).  The problem we have is that every time we send a 
 >      large image to be printed out to the Imagen, other smaller jobs
 >      entered on the queue at a similar time myteriously get lost !
 >      i.e. they never print out !
 >      
 >      Does anybody know what causes this ?  Has anybody had a similar problem ?


Let me answer this one.  The problem is that there is a bug in the
4.2 spooler that Imagen has been distributing.  Application support knows
about the bug, and it has been fixed in the latest spooler distribution
tapes (v2.2).

When the spooler attempts to open a tcp connection to the printer, it
executes a loop something like this:

        s = socket(...);
        for (;;) {

            if ( connect(s, printerid) < 0 ) {
                if ( errno == TIMEOUT || errno == REFUSED ) {
                    sleep(60);
                    continue;
                else {
                    send message to a log file that is destroyed immediately (!)
                    die.
                }

            }
            /* connection is open */
            send_file_to_printer.
            break;
        }

The problem is that connect destroys the socket with which it was called
when it fails, such that future calls to connect return immediately
complaining of an invalid socket.  This causes a message to be logged
and the spooler to abort the job.  As luck would have it, the message
is logged to a log file that is destroyed between print jobs, so it
only exists on the system for about 1 second (!).  The bug isn't mine
(I didn't write this code), but a perusal of the relevant documentation
for connect(II) would not lead one to believe that this is the true
behavior of the connect call.

The fix is to move the socket call into the loop and explicitly close
the socket each time a connect fails:

        for (;;) {
moved---->  s = socket(...);

            if ( connect(s, printerid) < 0 ) {
                if ( errno == TIMEOUT || errno == REFUSED ) {
new------>          close(s);
                    sleep(60);
                    continue;
                else {
                    send message to a log file that is destroyed immediately (!)
                    die.
                }

            }
            /* connection is open */
            send_file_to_printer.
            break;
        }

In practise, there are several lines around the socket call that must be
moved, but the change is straightforward (if it isn't clear from the above,
contact application support at Imagen - (408)986-9400).

By the way, you may wonder why this bug was only being exercised when
the printer was processing large jobs.  The printer only accepts one
TCP connection at a time.  The probability of hitting the printer while
it is communicating with someone else is higher when the printer
is receiving data for minutes at a time.

- Geof Cooper
  Imagen