medin@cincsac.arc.nasa.gov (Milo S. Medin) (06/21/89)
In article <Added.4YbcHe200Ui3EK=E8S@andrew.cmu.edu>, REWING@TRINCC.BITNET writes: > Milo's comments regarding Appletalk may have had some valid points in > phase I Appletalk, but I thin he's missing the point regarding Appletalk's > functionality. There are those in this world that believe that TCP/IP is the > end all, be all network that everyone should adopt, bar none. While > IP has its definite advantages, have you ever tried to set up an IP network? Actually, I design IP networks for a living. I'm the lead engineer on the NASA Science Internet Project, building international networks for NASA Science. So yes, I do it all the time. So do naive users who install SUN's out of the box... > Ever try to add new users? Does anyone really know what "192.32.2.0" means? Actually, it's not that hard. You can use a number of tools like rarp for address assignment. Ever wonder how a diskless workstation gets it's address? Same sort of problem... > Do you really want to do that kind of support? Oh sure, setting up your > favorite Sun, Apollo, Vax or Cray on time might be okay. But most > Mac sites are hardly static, as people come and go, students come and go, > and devices and added and removed from the net more frequently. Appletalk > was built with ease of use in mind. Sure its not the most efficient > protocol in the world. But that's hardly a reason to pick-up IP just because > of throughput benchmarks. Again, it's not that hard, you could modify the tools to do much of this dynamically, much as Kboxes assign IP addresses dynamically to Mac's now... Ease of use eh? What happens when you have 50-100 appletalk nets all trying to interoperate with each other? How easy is it to make that work? A lot harder than the equivalent IP or DECNET networks... > The old Appletalk was admittedly a "renegade" protocol on Ethernet, forcing > every non Macintosh to listen to everything it broadcasted. The new > Appletalk is IEEE accepted, as the structure of its new packets indicates, > just like IP and Decnet. Now your Suns, Cray, or other machines no > longer have to listen to Mac packets, unless they want to. > That wasn't the point. The point is you guys are trying to kludge appletalk into being an real Internet protocol, and ignoring real internet protocols that exist today and are widely used. It's not just IP, there's DECNET and even some CLNP. The new Appletalk may be IEEE accepted, but do you use 802.2 LLC underneath? No. Just because it's documented doesn't mean it's a good thing. You are now standard in the ethernet MAC header. I'll grant that. > (continued in next message) > > -_Rick Ewing > Apple Atlanta > REWING@APPLE.COM The bottom line is not that IP or DECNET or OSI networks are easier to install and manage than ATP. The point is that they could easily be made that way using existing tools. It's a user interface issue, not a protocol architecture issue. It would have taken a lot less effort to build simple tools for IP to look as friendly as ATP compared to the amount of work put into building an inferior protocol from scratch. Instead, Apple built something completely different. And all those management tools and routing protocols and other things we use to solve problems in the IP world can't be leveraged in the Apple world. Sure, maybe it's not so bad when dealing with tiny networks. But one thing they certainly should have realized from networking experience is that sucessful small systems all turn into large systems. If you design with limited expectations, you outstrip the architecture when users try and build larger systems. And all of us have to suffer with the consequences. Thanks, Milo
rewing@APPLE.COM (Richard Ewing) (06/21/89)
Two good questions! First, if you run router on the same machine as a server, you must choose which network the Mac will actually show up under. So if you had an Ethernet network and two localtalk networks bridged by router, the Router software will give you a chance during setup to pick the Macs home network. That way, the server would appear under Ethernet, or the localtalk side in the chooser, depending on your preference. All machines on the network will be able to access the server, regardless of which side (Ethenet or Localtalk), simply by selecting the correct zone in the chooser that you have configured. I think (though I'm not sure) that Router has a little bit of intelligence not to reflect back packets that are destined for its home machine, but you never quite know these things. The only difference between the old and new Ethertalk cards is that the new ones have a few less chips, and probably cost us less to make (but will we charge less? nahhhh...). The functionality is exactly the same, so don't worry if you order some cards, and get the older models. --Rick Ewing Apple Atlanta REWING@APPLE.COM
ragge@nada.kth.se (Ragnar Sundblad) (07/23/89)
Hmm, Apple has announced AppleTalk Phase II. But what is it? I have heard that it has some new kind of routing/zoning/networking mechanism so that one for example can build EtherTalk networks with more than 254 nodes. What have they changed? How backward compatible is it? Anyone who knows?
eljazzar@utkux1.utk.edu (Mohamad El Jazzar) (11/06/90)
We are planning a campus-wide transition to AppleTalk Phase II and we'd like the change to go as smooth as possible (surprise!). Our major concern is compatibility with existing hardware (and software when applicable). Comments anyone? One more thing: what would be a good source of information on AppleTalk (other than Inside AppleTalk)? Mohamad El Jazzar Internet: eljazzar@utkux1.utk.edu Bitnet : eljazzar@utkvx