www.riscos.com Technical Support: Programmer's Reference Manual

Printer server protocol interface

NetPrint status protocol

Status enquiry packet

To request the current state of a printer server the client sends an 8 byte status enquiry packet to port &9F:

Byte	Meaning
1 - 6	printer name, padded with spaces
7	reason code (1 STATUS REQUEST_ 6 name request)
8	reserved (must be zero)

Status request

If the reason code is 1 (status request) the printer server should check the printer name. The check should be case insensitive, but with accents significant, preferably using Territory_Collate (see Territory_Collate):

• If the name matches the name of a printer connected to the server (eg 'PScrpt'), the server should send its status.
• If the name matches the string 'PRINT' or 'SPOOL', the server should send the status of the user's default printer. (With Acorn's !Spooler software, this is the most recently used printer, or the first listed printer if none has yet been used).
• If the name matches neither of the above cases, the server should not reply.

The status reply, if any, must be sent to port &9E:

Byte	Meaning
1	status: 0 READY_ 1 BUSY_ 2 JAMMED_ 6 Offline; all other values reserved
2	station number for Busy status, or 0
3	net number for Busy status, or 0

If the server is Busy, the second and third byte of the status packet are the station and net number with which it is busy. If the server is Busy with no particular station, or if the status is not Busy, these bytes should both be set to zero.

Using the name 'PRINT' is deprecated because it makes it difficult for a printer server that supports multiple logical printers. Wherever possible you should use the printer's name.

Name request

If the status enquiry reason code is 6 (name request) then the client is asking the printer server for its name. The name sent by the client is 'PRINT' or 'SPOOL', but it is not necessary to check this. The server must reply to port &9E:

Byte	Meaning
1 - 6	printer name, padded with spaces

If the printer server supports multiple logical printers it may send multiple replies with different names. If the client discards duplicate replies then it should take account of the name in the packet as well as the station and net numbers.

Flag bytes

For all status packets the flag byte currently has no meaning. Clients should send a flag byte of zero, and servers should send back the flag byte that they received from the client.

NetPrint printing protocol

Finding the status before printing

Before starting to print, the client should ideally send a status enquiry to the server to ensure it is ready (see above).

Establishing the connection

The connection is then established using packets where the flag byte is relevant. It has this meaning:

Bits	Meaning
0	sequence bit
1, 2	modes
3 - 6	task id
7	reserved (must be zero)

The client first sends a zero or one byte packet to port &D1 on the server, with the flag byte's sequence bit clear, and its mode bits set to 2_01. The task id bits of this packet's flag byte - and its data - are used to negotiate how to send the print data. Their possible values are dependent on the version of NetFS in use, and are as follows:

• If the flag byte's task id is 2_0000, then the client will only send data in &50 byte blocks.
  If any byte is sent it should be zero, but is ignored.
• If the flag byte's task id is 2_1000, then the client code is both asking for the allocation of a task id by the server, and trying to establish if the server can accept large blocks of data (up to the size returned by SWI Econet_PacketSize) or only small ones (up to &50 bytes).
  If a non-zero byte is sent, the client is also seeking to negotiate a features mask with the server. The bits show the features the client supports:

  Bit	Meaning when set
  0 †	Use reply port &D0 (allows local loopback etc to work)
  1	Print data is compressed (not yet implemented)
  2	Use dynamic port for data packets
  3 - 6	Reserved
  7	More features in extension packet (not yet implemented)

  † This bit must always be set if any other bits are set.

• Other values of the flag byte's task id are reserved.

If the server is unwilling to accept the print it doesn't send a reply. If it is willing then it replies as follows:

• If the client's task id was 2_0000, the server sends back a single zero byte to port &D1, with the flag byte the same as that it received from the client.
• If the client's task id was 2_1000, the server uses the flag byte to respond to the request for large packets and task id...
  • If the server isn't willing to assign task ids - and hence accept more than one connection from a single client - it sends back the client's (illegal) task id of 2_1000 (see below); otherwise it sends back a task id chosen from the ranges 2_0001 to 2_0111, or 2_1001 to 2_1111.
  • If the server can accept large blocks of data it sets the mode bits to 2_10, else it sets them to 2_01.

  ...and it uses the byte(s) it sends back to respond to any request for a features mask:

  • If the client did not request a features mask, or the server does not support any features, it sends back a single zero byte to port &D1.
  • If the client requested a features mask, and the server supports this, it ANDs its own mask with that sent by the client. If bit 2 is clear, the server sends the single mask byte to port &D0; if it is set, the server gets a dynamic port using Econet_AllocatePort, and sends two bytes to port &D0: the mask followed by the port.

The connection is now established. The client then examines the final flag byte sent by the server, changing a task id of 2_1000 to 2_0000. This version of the flag byte is the one that will be used when sending the data.

Sending the data

The client then sends the data in blocks, the size of which can vary from zero bytes up to the maximum established by the connect protocol. The data is sent to the dynamic port returned at connection time, if any; otherwise it is sent to port &D1. The flag byte for each block is the same as that negotiated when connecting (see above), save that the sequence bit is toggled for each block. This is to avoid duplicate data packets; the server discards and ignores any packets that have the same sequence bit as that previously received.

Acknowledging the data

Each time the server receives a new block and is ready to accept another, it must acknowledge the received block with a one byte packet. If the features mask negotiated in the connect protocol had bit 0 set, the reply is sent to port &D0, and the byte gives the status:

Value	Meaning
0	Ready (send next data packet)
1	Busy (don't send next data packet yet)

Otherwise the reply is a zero byte sent to port &D1.

The packet's flag byte must match that received from the client. Again, the sequence bit is used to avoid duplicates; if the flag byte of an acknowledgement received by the client does not match the packet it most recently sent, it is a duplicate of a reply to the previous packet, and so is discarded.

Closing the connection

When the client wants to close the connection, it sends a data packet with the mode bits set to 2_11. The data for this last packet must be terminated by an &03.

Port claiming

NetPrint claims ports &D0, &D1 and &9E with Econet_ClaimPort. A printer server should claim port &9F.