Path: utzoo!mnetor!uunet!btni!hdr!unocss!ca063
From: ca063@unocss.UUCP (Thomas Davis)
Newsgroups: comp.sys.amiga.tech
Subject: Amiga Networking
Message-ID: <268@unocss.UUCP>
Date: 9 May 88 21:56:38 GMT
Organization: U. of Nebraska at Omaha
Lines: 208
Keywords: Amiga, Networking

[chomp chomp chomp]

    After hearing all the talk about networking for the Amiga, and IPC,
I've decide to take a bite, and publish a little note on WHAT it would
take to make a SIMPLE network for the Amiga.  Do understand, by Network
I mean more than two devices on a serial linie (DNET currently only supports
UNIX to UNIX, Amiga to Amiga, or Amiga to UNIX style..(and I STILL can't get
DNET to work with a Ethernet DECserver))

    This document describes the notes I have made on networking for the
Amiga.  This shall describe the hardware necessary, the software
protocol, and problems.

    The hardware:

    The networking hardware shall consist of a Zilog 8530, driven off of the
Amiga's expansion connector.  It will auto-config, to prevent conflict with
other possible devices.  The Z8530 is capable of a multitude of special
serial functions.  I would suggest reading the technical manual available
from Zilog about this device.  The hardware will also support another serial
device, capable of speeds well in excess of 38.4kbps.

    A short description of the Z8530:

    The Zilog Z8530 is termed by Zilog as an "Universal" device.  It was
designed from the beginning to be used with many different CPU's.  This device
supports Synchronous as well as ASynchronous operation.  The network I am
about describe uses the Synchronous mode of this device.  This device allows
the network to send packets to different systems (based on HDLC,) allowing
the destination to be the only system that has to be aware of the packet.
It also supports a broadcast address, for all systems to become aware of a
request.  The only problem of this device is the limit of 254 devices,
but if the network grows that big, a new & better net.device should be used.

    The system will also use RS422 as the electrical standard to connect the
networking devices, since 422 can support upto 10Mbps transfer rate.  With
this capability, the Amiga and the 8530 can easily support in excess of
250kbps (for the layman, that's about 31k Bytes/sec) over several thousand feet
of twisted pair cable.  Also, for those that are interested, this device
can also support AppleTalk (local talk).  The only thing necesarry would
be the connector to the cable, and the software.

    As for the auto-config logic, I'm still working on it, since I don't have
a PAL programmer available here.

    Software:

    The net.device would look like a normal device to AmigaDOS, in fact,
the only difference I can think of having is a packet to tell it to
establish/break a virtual connection with a machine, and adding a field to all 
the packets the net.device gets (AmigaDOS packets) to determine what goes 
where.  The network addressing, the packet type, packet routing would all be
invisible to the user.  If everything goes right, DNET should work out of the
box, with the change of being able to specify a host/client name.

    Now, everybody probably is saying "What good is a net, if I can't use
it to print, copy files, or even run a program on the other machine?"  The
net.device doesn't care about those things; it's just there to see that
infomation gets from your computer to the network host/clients.  It only knows
how to format a packet, send it, receive them, build a list of possible hosts,
and inform the net of problems.  This problem will be discussed at a future 
date & time.

    Assigning Nodes:

    First, everybody on the net would have to name their machine.  This
would go into a file in S:, let's call it net-info.

    The format of net-info would look something like:

    "my-amiga"   Which would be the node name.
     
    This allows the user to name his node.  I would rather know what my 
node-name is rather than a number.  Now, the problem exists of mapping the 
node name into a network ID number.  To solve this, the system will on boot
broadcast a "PING" packet, with it's id equal to 1.  The system then
will collect all the replys, building a list of possible nodes/ids.  At this 
time, the net.device can then dynamically pick it's own id, and it will then 
broadcast over the net again a "PING" packet, this time with it's own id in
the TO field.  At this time, if nobody has claimed the packet, the net.device 
can then safely use the list as valid, else we just start over again. (This
also allows the chance for the rest of the net.devices to validate their
own list of nodes.)

    By this point, the net.device should have built a valid list of nodes
on the network.  Now, the net.device does not know what node has what
available to the network.  Again, that will be discussed in a seperate article;
this article is simply about the network protocol.

    The packet format:

    The format of the packets used in this system is based on two seperate
issues;  size, and hardware dependency.  The size of the packet will be 
variable, but will look like so:

   --------------------------------------------------------------------
   | SYNC | SYNC | TO | FROM | PAK # | COM | DATA | CRC | SYNC | SYNC |
   --------------------------------------------------------------------

     The SYNC fields is for the hardware, and will not be considered part of 
the packet.

     The TO field and FROM fields are each 1 byte in size.  The reason 
a FROM field is included is to allow direct replys BACK to the device that 
sent it.

     PAK # (also 1 byte in size) is a number for the system to keep track of
what packet it has sent/recieved, so it can send information back to the
sender about it.

     COM (again, 1 byte in size) is used to determine the packet TYPE,
IE. if it's a command packet, or data packet.

     DATA is the heart of the packet.  This can be ANYTHING.  Length?
Undetermined at this time.  It will probably be UNDER 1k in size.

     CRC is generated by the 8530, and so not considered part of the
net.device problem ( it will handle detecting if a packet is BAD though..)

     SYNC is back to the beginning.

     Packet Types:

     Command packets:

      To field of packet is set to 255 ( Net broadcast );

      1. PING     - Everybody send their node number, and node name.
                    IE. data field will hold node name, FROM field is
                        node number.

      2. DEATH    - node going down, remove from node lists
                    IE. from field holds node number of who's going down.

      3. OVERRIDE - priority message, everybody shutup and listen
                    IE.  Somebody wants the net NOW.  from field says WHO.
                         (could be used to boot a device over the net)

      If the TO field has a valid node ID in it:

      1. PING     - To see if the node is still up.
                    (same as command, except send to FROM field)

      2. OVERRIDE - Tells the node that I am in charge, forgot everybody else
                    (get's the node's attention)

      3. ACK      - packet ID(s) in data field arrived OK.
                    (used to send OK message to sender.  Allows the ability
                     to ACK more than one packet at a time.  The data field
                     holds the packet #'s that are to be ACK'd)

      4. NACK     - data field contains ID's of NACK packets.
                    (same as ACK, but NACK of packets..)

      5. DATA     - data field is valid.  Please use, and return ack/nack

      6. LINK     - data field contains a request for opening of link.
                    (data field holds the request for what; this
                     just tells net.device to expect many requests from
                     this link)
      7. UNLINK   - data field contains a request for closing of link
                    (opposite of LINK)
      
    Collision Detect/Sense:

       A big problem, esp. with this type of network.  To solve this problem,
is where the NAK/ACKs come in play.  The net.device will first listen to the
network.  If an another machine currently is transmitting on the net, it will 
wait for the other system to finish.  Once the other system has finished, it 
will wait a random amount of time more, and THEN attempt to transmit it's 
packet.  The net.device will then WAIT for a certain amount of time (say, 100 
millisecs), and if a reply has not been received, it then mark the packet as 
lost, and retransmit it.  Now, if it DID get through to the device on the first 
try, but the host doesn't have time to respond ( which could happen), it will 
discard the packet upon receipt of the new one.  The system will have a finit 
amount of time to respond to the new packet.  This will continue until the 
transmission of the packet to the other device is successful.

       The system will also allow several packets to queue up at the receiver 
end.  This allows the system to use the network bus to the fullest extent, by 
doing a burst transmission, and then allowing a efficient 1 packet ack/nack of
the several packets (note - I am thinking along the lines of 4 packets max 
queued up.)

        Net.device will not throw a packet out until it 1) can't get through to 
the other hosts or 2) it's been ACK by the other host.  If after several packets
have been transmitted, and the timer has expired, it will wait a random amount 
of time, and then attempt to transmit a PING packet to the device.  If the 
host responds, it will then retransmit all packets it still has.

       If the host does not respond, it will be marked in the host table as
"unreliable".  This means the net.device will PING it before attempting to
connect to it on the next packet to be sent to it.  If the PING fails, the
host will be the marked in the table as "dead", which means no packet will be
sent to it until a PING packet from the host marked dead is received from it
(IE, machine guru'd, when it comes back up, it does a "network" PING.)  If 
the PING succeds, the host will be marked as active, and everything will be 
back to normal.

       If a "network" PING is done, net.device will build a new table and
discard the old table, therefore dynamically updating it's routing tables.

    In conclusion, any comments are welcome.  None of this has been implemented
yet;  I'm still in the design stages.  Do note, this is just some ideas I've
had.  I hope to have something in working form by the end of May, but I
make no promises.

    Thanks.