ca063@unocss.UUCP (Thomas Davis) (05/10/88)
[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.rminnich@udel.EDU (Ron Minnich) (05/10/88)
In article <268@unocss.UUCP> ca063@unocss.UUCP (Thomas Davis) writes: > This document describes the notes I have made on networking for the >Amiga. This shall describe the hardware necessary, the software >protocol, and problems. Folks, this stuff is real nice, but forward motion for the amiga requires that we stop re-inventing wheels. The BSD tcp/ip package is available for porting to the amiga, no one can sue you anymore, SUN's rpc is available, NFS is available, why on god's green earth are we defining new networking standards/packet formats/Address Res. Protocols/naming conventions/ad infinitum? TCP/IP SOURCE is freely available, all the new LAT-like boxes talk SLIP at 38.4, let's GO FOR IT! Louis Mammakos tells me he is going to do it, I want to try it this summer, but Thomas if you want get in touch with me and i will be glad to talk it over with you. The software is there for the taking! And it is good stuff- the same stuff 4.3 is using now! Same comments apply here as apply to supplanting (as opposed to supplementing) IFF. -- ron (rminnich@udel.edu)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/11/88)
: This document describes the notes I have made on networking for the
:Amiga. This shall describe the hardware necessary, the software
:protocol, and problems.
Uh oh... please, lets not get into an implementation level
discussion of *networks*. Having real-life experience with the design
and implementation of several links (2 hosts) and two networks (many hosts),
I can tell you right off that:
(1) Hardware isn't the problem. Hardware is simple
(2) Writing the network driver software IS the problem
(3) It is not a trivial problem, period. Even if you were
to break it down into the simplest of forms it is not
trivial.
What you need to be able to do. This is assuming you already know all
the hosts on the net, that now routing will be done, that no fancy
streaming will be done (read: not a windowed protocol). Thus since
throughput is going to be lousy anyway we don't have to worry about
optimization of the bandwidth.
(a) Low level control protocol
(1) timeouts for retries
(2) timeouts before giving up retrying
(3) what happens when one end can't receive?
(4) handling duplicate packets (difficulty depends on (6)).
(5) timeouts timeouts timeouts and more timeouts
(6) independant control information vs sequenced control
information. control ordering information. Does the
protocol allow
simultanious control aspects from a specific host to another
specific host or must control information be sequenced on a
host<->host basis (i.e. if host A opens two connections to
host B simultaniously, can host B handle the low level
control protocol that establishes the connections both at
once or must the two requests be ordered... first resolve
connection one, then connection two, etc...).
If sequenced, duplicate packet removal at the low level
becomes trivial.
(7) system resets... avoiding confusion
(a port is a logical ID. A given host has many ports).
(b) Establish a virtual connection
(1) a: hello, I would like to connect to you. I'm on port A
b: hello, sure, ok. Please talk to me on Port B. I'll
talk to you on Port A.
(A goes away)
(2) timeouts on open sequence (assuming you are not overlaying
open/close/control sequences on another protocol).
(3) timeouts on already allocated ports when something fails.
"can't reuse the port for X minutes because the other guy
might think he has a connection"
(c) send-receive data on a virtual connection
(1) data buffering
(2) data sequencing not a problem 'cause we don't have a
windowed protocol.
(3) stay-alive (usually a 0-length control info on the
secondary channel).
(4) control information (secondary channel)
(5) flow control
(d) close down and EOF
(1) Allow one end to terminate sending but still receive?
(send EOF, continue reading until get EOF).
(2) close down sequence:
a: I'm done! Are you done?
b: OK, your done!
a: OK, I know you know I'm done
b: OK, well I know you know that I know I'm done
Now if you start adding the things you *need* for a *real*
network, things get even more complex. For instance, if you
allowed your stream connections to use a windowed protocol
(several packets in transit before the first ACK comes back),
you suddenly have to worry about:
(1) sequencing of the stream data. Short description,
dirty non-trivial problem.
(2) more complex flow control and buffering
So please, lets not get into a discussion... Look at DNET and what
you will see is a lot of hardwork. Most of that was implementing
the windowed protocol. I got around having to implement low level
control protocols by making DNET a LINK (only two hosts). Thus,
all the control information can be embedded onto a single stream
whos low level interface is the windowed protocol. With a NETWORK,
you cannot do this. It simply does not work.... To implement
a windowed protocol on a network you have to do it on a connection
by connection basis rather than a host<->host basis because there
are simply too many hosts to deal with.
-Mattjbn@glacier.STANFORD.EDU (John B. Nagle) (05/12/88)
I'm suprised that someone would object to discussing networking on the
Amiga, which is certainly a legitimate technical subject.
First, hardware is a legitimate problem. There's a tradeoff between
bandwidth and cost. RS-232 stands at one of the spectrum, Appletalk
in the middle, and Ethernet at the high end, at least in the microcomputer
world. Unfortunately, the Amiga lacks built-in support for a network other
than the RS-232 ports. So a hardware add-on will be required for any serious
networking.
Technically, it's not clear that you really want a virtual circuit
protocol on a LAN. I spent years working on TCP, both from a theoretical
and implementation standpoint. But today I would argue that systems like
NFS and TOPS may be more appropriate. On a modern LAN, most transfers are
treatable as remote procedure calls or file accesses. The remote-terminal
orientation of the ARPANET belongs, to some extent, to the past.
Inventing one's own homebrew protocol at this late date is a terrible
mistake, though. It's far better to be compatible with something already
in existence. This is, after all, a communications problem, and the more
things that you can potentially communicate with, the more useful the
communications system is.
If you want to implement something, I'd suggest NFS over UDP over IP
over both RS-232 and some reasonable LAN for which Amiga hardware is available.
The protocols are well known and have been implemented by many different
people. They are used widely, work adequately, and provide good performance.
Public domain implementations for the IBM PC are available.
John Nagle
protocols are independent of the communications medium.
So far Commodore has not, as far as I know, endorsed or supported
any of hte mende@porthos.rutgers.edu (Bob Mende Pie) (05/15/88)
I agree with Ron, the most important thing for a network for the
amiga is *COMPATIBILITY* One of the new keywords in the computer
world is NETWORK. And the biggest kind of network is TCP/IP network.
TCP/IP is the standard network of all BSD unix machines. Soon it will
be the standard for at&t unix as well. VMS versions of TCP/IP are
available from many places (rumor has it that this will include DEC in
the future). It is the type of network that most of the IBM/PC's
use. In other words, it is a standard. With the slip drivers, you
can do lots of useful things just by connecting to a serial port of a
machine, or a terminal server (I do this). If you get a true ethernet
card (ameristar has a nice zorro ethernet card), then you will get
very high speeds. TCP/IP has lots of error correction built into it.
I see any other choice as a nearsighted mistake.
/Bob...
--
{...}!rutgers!mende mende@aramis.rutgers.edu mende@zodiac.bitnet
Didn't I buy a 1951 Packard from you last March in Cairo?RDBROWN@UALR.BITNET (03/29/90)
Look for AmigaNet to come out pretty soon now. There's been a preliminary announcement in Amazing Computing recently. RDB