[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NadaNet 3.1 Released

Jonno Downes wrote:

On May 28, 1:16 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:


Much of this simplicity is obtained by assuming that all communicating
machines are on the same physical network, seeing the same signals at
the same time as all other machines.  A NadaNet router or even switch
was never planned and not designed for.  The protocols are all real-time
protocols and are intolerant of what we today call "network delays",
so bridging NadaNet to an IP network is not really possible.



So I'm not saying it would be useful, but from further review of the
specs, it looks like an IP<->NadaNet bridge would be *possible* if the
device doing the bridging locked the NadaNet bus (i.e. output a
consant high signal) whenever it got a packet that needed to be
delivered to a remote network via IP, and released the bus when an
appropriate response packet has been sent back over the IP tunnel (or
after say a 500 ms timeout to allow eventual recovery from broken IP
connections).


Good job interpreting the specs!  ;-)

There is currently a "lock" time limit of about 30 milliseconds,
which is plenty for NadaNet, but would prevent this from working
for a router.  It is clearly bad to keep NadaNet locked for very
long, since it effectively shuts it off.

A better way would be to count on any requester retrying for a
period of time (defualt is about 3 seconds, but can be easily set
by a command), and handle the request between first try and some
later try (i.e.:  withhold the ACK until the request is handled
on the other network).  There may be issues, but this approach
leaves the local NadaNet functional during the routed request.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."