home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / protocol / appletal / 3927 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.8 KB  |  73 lines
  1. Newsgroups: comp.protocols.appletalk
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!spool.mu.edu!agate!apple!mumbo.apple.com!gallant.apple.com!pyd.apple.com!buzz
  3. From: Steve Bollinger <buzz@apple.com.>
  4. Subject: Re: RTMP question
  5. Sender: news@gallant.apple.com
  6. Message-ID: <1992Nov16.224057.9133@gallant.apple.com>
  7. X-Useragent: Nuntius v1.1.1d12
  8. Date: Mon, 16 Nov 1992 22:40:57 GMT
  9. X-Xxdate: Mon, 16 Nov 92 22:42:09 GMT
  10. X-Xxmessage-Id: <A72D63C17B013847@pyd.apple.com>
  11. References: <don-131192134021@nocmac.cis.brown.edu>
  12. Organization: Apple Computer, Inc.
  13. Lines: 58
  14.  
  15. In article <1e605dINN44o@roche.csl.sri.com> David Stine, dstine@cisco.com
  16. writes:
  17. >It is also possible that collisions can take out RTMP update packets
  18. after
  19. >they have been sent by the router. This is somewhat less likely.
  20.  
  21. AppleTalk was designed to run on LocalTalk, which has no collision
  22. detection. Losing RTMP packets on LocalTalk is not a terribly rare
  23. occurance. So any good implementation should have no problems with
  24. lost RTMP packets.
  25.  
  26. >
  27. >>My question comes up because if I sit at the console of the Novell print
  28. >>server and watch the RTMP table, the next hop route to any given IP
  29. site is
  30. >>doing a 'musical chair routine' among the 30 some FastPaths.  Every 10
  31. >>seconds or some the next hop changes nodes on the ethertalk segment!
  32.  
  33. You probably don't mean IP here. Or maybe you don't mean RTMP. What do you
  34. mean?
  35.  
  36. >Well, this is something of an open area in the AppleTalk end-node design.
  37. >Implementors who follow "Inside AppleTalk" to the letter will have their
  38. >designated router possibly switch with every incoming RTMP packet. Please
  39. >refer to pp. 5-18 and 5-19 in "Inside AppleTalk", 2nd. Ed.
  40. >
  41. >Some would say that this is a nuisance in AppleTalk, that it confuses the
  42. >issue of trying to figure out where your traffic is going and why. These
  43. folks
  44. >tend to come from the IP world, where you either tell a Unix host to
  45. >(statically) designate a default route to a router for all traffic or
  46. you are
  47. >running a routing protocol which tends to "lock on" to a path.
  48. >
  49. >So there are some AppleTalk end-node implementations which tend to stick
  50. with
  51. >the first router they hear as the value for A-ROUTER until they quit
  52. hearing
  53. >said router, at which time they pick another router on the cable.
  54. >
  55. >Then there is the flip side of the coin: by switching the value for
  56. A-ROUTER
  57. >with every update, you effect a sort of "load sharing" between the
  58. routers
  59. >present on a cable.
  60. >
  61. >Which is better? I'm sure we can find arguments in favor of both.
  62.  
  63. Actually, it doesn't really matter much which you do, as long as you
  64. implement
  65. the "Optional best-router cache" described on Inside AppleTalk (V2) p
  66. 4-20.
  67. All but the most rudimentary of network devices should be able to
  68. implement
  69. this cache. If you do this, then the only thing A-Router does for you is
  70. tell you where to send your NBP requests.
  71.  
  72. -Steve
  73.