Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!cincsac.arc.nasa.gov!medin
From: medin@cincsac.arc.nasa.gov (Milo S. Medin)
Newsgroups: comp.protocols.appletalk
Subject: Re: UDPTalk as a backbone
Message-ID: <31397@ames.arc.nasa.gov>
Date: 6 Sep 89 02:14:26 GMT
References: <1989Sep5.192546.15473@caen.engin.umich.edu>
Sender: usenet@ames.arc.nasa.gov
Organization: NASA Science Internet Project Office
Lines: 91


In article <1989Sep5.192546.15473@caen.engin.umich.edu>, billkatt@caen.engin.umich.edu (billkatt) writes:
> 
> >My point was that we restrict Mac connections to Appletalk nets to localtalk
> >speeds (since we don't allow Mac's to run Ethertalk on the LAN, only TCP/IP).
> >The high speed applications are generally better served by IP protocols.
> 
> Hmmm... You're not the first person I have heard of who does that.  Is there
> an overriding reason?  I don't see one.  Or do you use a different physical
> backbone for IP as AppleTalk?

Our buildings typically come pre-wired for RS232, Localtalk (PhoneNet),
and ethernet.  Relatively few Mac's have ethernet controllers in them,
so they need localtalk and Kinetics boxes anyways.  Mac's can certainly
buy ethernet controllers and run TCP/IP over them, but we do not allow
them to use Ethertalk.  That's the overriding reason.  We ban Ethertalk
from our basewide network.

> >Ahem.  IPtalk (as implemented by KIP) existed before Kinetics did.  I recall
> >early implementations using the famous Stanford "Butcher-block" gateway.
> >When Kinetics started making gateways (based on the Stanford design), KIP
> >of course ran on it.  For awhile, it was the only thing that ran on
> >that hardware.  IPtalk actually predates Ethertalk!  Atalkad is VERY
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Isn't that what I said?
>

You said Kinetics invented UDPtalk.  That's simply not true.  Bill Croft
and the SUMEX folks did, and before Ethertalk was in existance.  I will
take this oppurtunity and apologize for having my facts screwed up 
however.  The Butcher block gateway was a CMU effort.  The Stanford/SUMEX
effort was the SEAGATE gateway, which turned into the FastPath line.  KIP
always ran on the FastPaths...
 
> We currently run atalkad.  It is holding us back, but the Proteon software
> isn't available for about two months.  We won't have users on the net
> configuring the K-boxes.  It will be necessary to physically go to a box to
> reconfigure it, but we feel that is better than having Joe User set up his
> own box.  Thankfully, K-boxes require little maintainance once they are set
> up (unless you are running atalkad, whih wreaks havoc on them) so we will
> only have a problem when we update the software on the FastPaths.
> 
> Stats don't mean much to us.  We don't really consider LocalTalk a viable
> networking scheme.  We recommend EtherTalk as the lowest speed that is
> viable.

Well, I can undersatnd why people like Proteon want to support Appletalk.
I wish they'd work on more productive things is all.   As for Atalkad,
it works fine with the LBL KIP.  Those boxes stay up for weeks
at a time.  Maybe it drives K*Star crazy, but we have never gotten a 
piece of Kinetics software to do what we want, and the LBL KIP does, so
that's what we run.  It works very well.  Localtalk has to be dealt with.
It comes on all the little monsters.  Stats mean a lot when you find out
that your Phonenet is dropping 5% of it's packets because of CRC errors!
Then you can call out your ops people to actually fix the problem!
As I said before, the high bandwidth applications typically use TCP/IP
here, and that runs over ethernet.  We have localtalk anyway, so this
combonation solves a big problem (Ethertalk) with low marginal cost.

 
> Apple's Internet Router is a fantastic way to join LocalTalks to a backbone.
> You can join two LocalTalks and a combination of 6 EtherTalks and TokenTalks
> with one machine which can also function as an AppleShare server.  So
> LocalTalks and FastPaths don't go hand-in-hand anymore.  40 FastPaths and
> no end in sight?  I can see and end.  You will have to split your network into
> multiple networks or stop expanding when you reach 64 networks.
> I am kind of worried about having to run around to re-configure our FastPaths
> but we simply have no choice.  We can't use atalkad anymore.  We have a 
> FULL table.

I'm sorry, Apple's Internet router is rubbish.  How do you do net
management and control?  SNMP? CMIP?  Nothing is not an acceptable 
answer!  It doesn't perform IP gateway functions, so our NCSA Telnet
users can't talk to the rest of the systems on base though it.  We have
major mail applications on base (MacPOP) that our management people
use to read mail that requires CAP interoperation.  How does the Apple
IR do that?  I'm sure it does a fine job of doing LocalTalk to Ethertalk.
That however, is a solution to a problem I don't have.  And again, you
have to figure net management into the equation. Things occaisionally
do go wrong... :-)

Run out at 64 nets?  That's just a constant in the KIP code.  Source 
is great.  Maybe KStar can't deal with it, but we don't run KStar...

If you are looking for the mod, change NANETS to 96 or 128 or
whatever.  Make sure the KIP code you use also can deal with it.  
As I said, source code is great.  It's in the UNIX tradition 
of course, not the Mac tradition...

						Thanks,
						   Milo