Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon From: dillon@CORY.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Amiga Networking Message-ID: <8805110808.AA29075@cory.Berkeley.EDU> Date: 11 May 88 08:08:29 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 98 : 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. -Matt