Want a standalone server for running programs on
a transputer.  Reason for not using iserver: need to
be very efficient on file access.  Could hack iserver.
I think the main reason for not doing things that way
is that I'm too lazy to learn how iserver works in 
detail.

General io
----------

    Tempted to produce a server which just gives
remote access to unix io primitives.  Problem is
how to do ioctl's in a general way.  Suspect I can't,
because in general they take pointers to c structures.

     Most of the time don't need ioctls anyway, but it
would be nice to leave some sort of hook into them
in case they are ever needed.

     Need a mechanism for sending a fairly general c
structure over a link (assuming the server has already
been taught about the structure).  Shouldn't be much
of a problem really to just add this to the protocol later.

Terminal io
-----------

     To achieve terminal independence it's probably
not a good idea to use the general io mechanism to
handle the terminal.  Probably simplest just to use
term.p protocol, and rip corresponding bits out of
server14.

Optimising comms
----------------

     Packets sent from sun to niche can just be sent
with all their bits in one character array.

     Packets sent from niche to sun can be sent as follows:

     If the total amount of data in the packet is <= H,
send H bytes to the sun - containing the data at the start
and junk in the remainder.  If the total amount of data
is > H, send the first H bytes of data in one packet and
the remainder of the data in a second packet.

'H' should be chosen so that the time to send H bytes
from niche to sun is only slightly greater than the
setup time for sending a single byte - but as large
as possible given that that criterion is satisfied.
So sending H bytes does not cost significantly more 
than sending less than H bytes.  In other words sending
all the junk doesn't cost anything for small packets.
In any case H should be large enough so that the total
data size can be determined from the data in the first
H bytes - this is likely to be the case for any sensible
packet format (in which the data length is probably the
second word after the tag, say) and for any plausible
H, given the large set-up time achieved by the niche
card driver software/hardware.

     This scheme means that anything sent to the transputer
or anything of size less than H received from the transputer
only suffers one set-up time.  Anything of length greater than
H received from the transputer suffers only two setup times,
but this seems unavoidable if packets can be of variable
length anyway.

    The only change at the transputer end is that any packets
of length less than H to be sent must be padded out to length H
precisely.