TCP/IP Stream Print

TCP/IP stream implementation and enhancement

TCP/IP Stream Print is a description of the TCP stream protocol which is an output filter option in the EtherShare spooler for communication between spooler and RIP or printer. TCP stream is a standard UNIX protocol. We recommend TCP/IP stream for TCP/IP RIPs because application programs are able to interrogate printer font lists, receive printer error messages and abort print jobs which are already processing. It is simple to use, and also compatible to Telnet. A disadvantage is that TCP/IP requires a small driver program (provided with EtherShare) which passes error messages to the user and controls the printer. Nonetheless, it is still possible to print (without error feedback) using Telnet-like connections.

EtherShare PostScript output via TCP/IP

The HELIOS EtherShare UNIX-based AppleTalk networking software supports several possibilities to drive PostScript printers: (a) Windows SMB/CIFS connection (“smbif” output filter), (b) EtherTalk/LocalTalk connection (“papif” output filter), (c) TCP/IP connection (“tcpif” output filter), and (d) “remote lpr”.

For more detailed information see “The HELIOS printing system” in the HELIOS Base manual.

The TCP/IP connection is implemented with the TCP/IP stream protocol. Compared to remote lpr, TCP/IP stream has the advantage that application programs are able to interrogate printer font lists and receive printer error messages. It is also simple to use, since TCP/IP stream is compatible to Telnet. The HELIOS TCP/IP stream implementation functions as follows:

  • The RIP or printer waits passively for a stream connection through a specified port (e.g. port 4000, with the suggested service name TCP_PAP).
  • When a print job is received, the UNIX lpr printing system makes an active connection to this port, which is then used to pass the job as a stream to the RIP.
  • The RIP returns any error messages and the response from PostScript programs to the host using the same port, and the host stores the received messages in a log file.

Even if the RIP is busy processing a job, it should still not reject a connection request from the host. Instead, it should accept the connection request, return a suitable status message and close the connection again immediately. A typical status message is:
%%[job: dave@test document; status: busy; source: TCP/IP]%%

The output filter “tcpif” should evaluate the value of the “status” keyword as follows: all values with the exception of “idle” indicate that the RIP is busy, whereupon “tcpif” should wait for a predefined time before repeating the connection request.

A separate mechanism should be provided to send an interrupt to the PostScript interpreter to allow a very long job, or a faulty job, to be cancelled. The HELIOS implementation uses an additional control port, e.g. 4001 (suggested service name TCP_CTRL) for this purpose. The additional port provides binary transparency to the control signal, which might otherwise be interpreted as part of the print job (e.g. as binary bitmap data). The following two facilities are provided:

  • Whenever a print job needs to be cancelled, the HELIOS spool system sends a single data byte of 0x03 (CTRL-C) to the RIP, which should cause the RIP to immediately cancel and flush the job. This should be implemented in a similar way to the interrupt mechanism on a serial connection (execution of an “interrupt” operator).
     
  • Whenever an interpreter status check is required, the HELIOS spool system sends a single data byte of 0x14 (CTRL-T) to the RIP, which should cause the RIP to return a status message with the syntax described elsewhere.

The above design is also compatible with RIPs without the additional TCP/IP control port, but in this case you lose the ability to check interpreter status on-the-fly and to immediately cancel print jobs.

Error and status messages should have the following syntax:
%%[keyword1: value1; keyword2: value2; ...]%%

The HELIOS “tcpif” interface currently recognizes the following keywords:
 

“status”
RIP status. All keyword values (such as “busy” or “processing”) with the exception of "idle" indicate that the RIP is busy.

“PrinterError”
A serious error has occurred. The entire message is echoed by “tcpif” to the system console immediately. For LaserWriter like printers, typical keyword values of “PrinterError” are “Paper Jam” or “Paper Empty”.

“Flushing”
A previous syntactic error has prevented the job from being completed, and all further data received for this job will be ignored by the RIP. The “Flushing” keyword causes “tcpif” to cancel the job immediately and ignore any additional fields in the message.

Q&A on the HELIOS enhanced TCP stream protocol
  • What is the TCP stream protocol?
     

The TCP stream protocol is an output filter option in the EtherShare spooler for communication between spooler and RIP or printer. It is a standard UNIX protocol, but what is unusual here is that:

  • it is not normally used between spoolers and printers.
     
  • HELIOS suggests using IP ports 4000 and 4001 as described above.

Examples of the TCP stream protocol are contained in standard UNIX programming books such as “UNIX Network Programming” by W. Richard Stevens, Prentice Hall.

  • Why does HELIOS recommend TCP/IP stream for TCP/IP RIPs?

The EtherShare TCP/IP stream protocol offers the following advantages / disadvantages over other TCP/IP connections & types:

+ Advantage:
Application programs are able to interrogate printer font lists, receive printer error messages and abort print jobs which are already processing.

+ Advantage:
Simple to use, since TCP/IP stream is also compatible with Telnet.

- Disadvantage:
TCP/IP requires a small driver program (provided with EtherShare) which passes error messages to the user and controls the printer. Nonetheless, it is still possible to print (without error feedback) using Telnet-like connections.

  • How does TCP stream compare to other TCP/IP connection methods?

Remote lpr connections offer the following advantages / disadvantages over other TCP/IP connection types:

+ Advantage:
The driver is contained as standard in BSD and System V.4 UNIX, and does not need to be provided separately.

- Disadvantage:
Error messages are not returned automatically to the user because remote lpr only provides a 512 Byte status block; printer font lists cannot be interrogated.