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