Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!netnews.engin.umich.edu!billkatt From: billkatt@caen.engin.umich.edu (billkatt) Newsgroups: comp.protocols.appletalk Subject: Re: UDPTalk as a backbone Message-ID: <1989Sep4.202733.6326@caen.engin.umich.edu> Date: 4 Sep 89 20:27:33 GMT References: <1989Sep3.063402.22872@caen.engin.umich.edu> <31297@ames.arc.nasa.gov> Reply-To: billkatt@caen.engin.umich.edu (billkatt) Organization: Computer Aided Engineering Network (CAEN), University of Michigan Lines: 82 In article <31297@ames.arc.nasa.gov> medin@nsipo.arc.nasa.gov.UUCP (Milo S. Medin) writes: >Steve, I completely disagree with you. Forcing router vendors to spend time >implementing more non-standard limited protocols is not what I want >my vendors to do. Here at Ames, we essentially banned Ethertalk on our >large bridged backbone network. We have not been sorry about the decision. I'm familiar with that situation. That's the way it was here until we found the limitations of UDPtalk. > >Ethertalk is one of the poorest implementations I have ever dealt with. It >broadcasts way more than is needed, and generates a lot more routing traffic >than necessary. UDPtalk or IPtalk is MUCH nicer, and all my routers can switch >IP. I don't see how you can say that. Phase 2 fixes many of the routing traffic problems of phase 1. As for the broadcasts, I agree. However, I don't see any other way to do name lookups. And name lookups ARE a good idea. They offer possibilities that other networking systems can't offer. I think Apple's interface to name lookups is poor, but their implementation is sound. I think the broadcast problem is overrated, though. With increasing processor speeds, the amount of overhead in receiving a broadcast not meant for you is becoming academic. And a little work on ethernet cards can make it so NO processor time is needed to reject broadcasts. We can't stay static with the times. Anyone who has a 10mbit ethernet for a backbone two years from now isn't taking themselved seriously. > >We sucessfully run IPtalk through routers all the time, and some of these >routers are BSD machines, which I seriously doubt will ever understand >Ethertalk. We do too, currently. We use atalkad. Is that what you use? > >Our Mac's which directly connect to ethernet speak TCP/IP on the ethernet. >It works fine. For Mac type applications, they have localtalk interfaces >which connect to K-boxes which use the IP backbone as a transit, and can >talk to CAP machines, etc... In general, if the application is performance >driven, it can usually by handled by IP (our Crays don't speak Appletalk)... I agree with what you say. MacTCP is quite fast and is a better idea for many Mac to Unix communications, anyway. What does that have to do with UDPTalk? CAP is the only exception (like I said), but CAP does not involve routing UDPTalk. > >If Kinetics and whoever else only support Ethertalk would support IPtalk >also, we'd certainly welcome them into our market of several hundred >if not thousands of Macs. I'm sure the people at LBL (who also ban Ethertalk >from their backbone) would also agree. Maybe you should research your facts. Kinetics INVENTED UDPTalk. The original FastPaths (1's) were invented to bridge LocalTalk to UDPTalk (EtherTalk didn't exist yet). What Kinetics doesn't support is atalkad and UDPTalk backboning. They don't support it at all, you ask them. I did. I was operating under the assumption they did and that everyone must be discontent with Kinetics. When I finally figured out that they only support it for communicating to CAP, it made sense. FastPaths work very well in that situation. > >In small networks, or even medium sized networks, I'm sure Ethertalk >works out all right. But you judge a protocol by how well it scales, >and Ethertalk doesn't scale very well at all. Large facilities like Ames >have a lot of unique problems to deal with. IPtalk solves one of them. >We like it a lot. Anyone that supports it in their products is part >of our solution space... If you are happy with UDPTalk, then you shouldn't be talking to me about scale. We were happy with UDPTalk when we were on a small scale, too. When you reach the limits of atalkad or don't want to spend $2500 per LocalTalk, you'll see it my way. Io hope people heed my warning. Many of you have probably read Dave Falkenburg's article on KIP/CAP. He was very pro-atalkad in that article. You should talk to him now (falken@caen.engin.umich.edu). If you read that article and found many good reasons to use atalkad and UDPTalk then, you should listen to me (or talk to Dave) and understand the reasons not to use UDPTalk now. We thought we had a great stopgap solution. We kept believing it until we had spent $100,000 on FastPaths. Then, within a few short weeks, we switched 180 degrees and realize we had spent about $40,000 too much. I finally have a little peace of mind, too, knowing that our network will finally work right again. If you are unhappy with AppleTalk, maybe it is for the same reasons I was. > Thanks, > Milo -Steve Bollinger (billkatt@caen.engin.umich.edu)