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.