www.riscos.com Technical Support:
To request the current state of a printer server the client sends an 8 byte status enquiry packet to port &9F:
|1 - 6||printer name, padded with spaces|
|7||reason code (1 STATUS REQUEST_ 6 name request)|
|8||reserved (must be zero)|
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):
The status reply, if any, must be sent to port &9E:
|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.
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:
|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.
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.
Before starting to print, the client should ideally send a status enquiry to the server to ensure it is ready (see above).
The connection is then established using packets where the flag byte is relevant. It has this meaning:
|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:
|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.
If the server is unwilling to accept the print it doesn't send a reply. If it is willing then it replies as follows:
...and it uses the byte(s) it sends back to respond to any request for a features mask:
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.
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.
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:
|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.
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.
NetPrint claims ports &D0, &D1 and &9E with Econet_ClaimPort. A printer server should claim port &9F.