The iserver Protocol
As already explained, the Inmos iserver runs on a host machine, and listens for incoming requests from a transputer client. When a request arrives, the iserver parses it, executes the I/O operation, and sends results back to the transputer network.
Basic Server Operation
The iserver spends its life in a loop, waiting on a
transputer link for a client request. Since iserver protocol information is
sent in packets (as explained below), a client request arrives in two parts.
First, the minimum packet length is transferred -- this is necessary because
the server does not know initially how long the incoming information will be.
From this minimum packet, the server then calculates the length of the actual
message, and reads the remaining packet. Next, the complete request is parsed,
and a TAG indicating the requested I/O operation is extracted. Based on this
tag, the server jumps to a routine which executes the operation. Each I/O
routine is responsible for constructing a return packet; upon completion, this
return packet is transferred back to the transputer network. The server can
then go back to waiting on the link. 
The Protocol Packet
The iserver protocol sends messages using packets which are counted arrays of bytes: two bytes indicating the length of the message, followed by the message itself:
A couple of restrictions are placed on the packet, to simplify server programming:
- min packet size = 8bytes (ie, min message length = 6bytes)
- packet size must be even
Server Commands
Over this basic protocol is imposed a higher layer: a one-byte TAG indicating the requested I/O function, followed by a variable list of arguments required by that function. Server I/O functions are split into three groups:
- file commands (eg, fopen, fclose)
- host commands (eg, getkey, pollkey, getenv)
- server commands (eg exit, CommandLine)
The following figure shows how the "fopen()" function would be expressed using the iserver protocol:
This example follows the Inmos implementation of the iserver protocol; however, note that there is a slight portability violation here. A filehandle should not, in general, be passed between different architectures. The iserver is essentially restricting filehandles to 32bits, which may not be the case on the host machine (this very problem was encountered in this project). Instead, since the client does not actually modify the filehandle, an opaque token should be passed, which is converted by the iserver into the proper filehandle in an implementation-dependent manner.
References
- Iserver manual