home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / protocol / appletal / 3916 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.9 KB
  1. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!eff!sol.ctr.columbia.edu!spool.mu.edu!sgiblab!news.cs.indiana.edu!noose.ecn.purdue.edu!sparkyfs.erg.sri.com!csl.sri.com!dstine
  2. From: dstine@cisco.com (David Stine)
  3. Newsgroups: comp.protocols.appletalk
  4. Subject: Re: RTMP question
  5. Date: 15 Nov 1992 17:07:57 GMT
  6. Organization: cisco Systems, Menlo Park, California, USA
  7. Lines: 44
  8. Distribution: world
  9. Message-ID: <1e605dINN44o@roche.csl.sri.com>
  10. References: <don-131192134021@nocmac.cis.brown.edu>
  11. NNTP-Posting-Host: regal.cisco.com
  12.  
  13. In article <don-131192134021@nocmac.cis.brown.edu> don@bodovipa.cis.brown.edu (Donald Wright) writes:
  14. > If a FastPath (Gator box, whatever) happened to be busy doing file transfer
  15. > for instance, could this affect the rate at which RTMP updates are sent, or
  16. > is it completely timer driven and/or has priority to send its packets.
  17.  
  18. I can't speak as to the internal design of FastPaths and Cayman routers, but
  19. in the internals of a cisco routers, I can say that this is possible.
  20. (if you get the router very busy with switching incoming traffic, the
  21. generation of _more_ traffic becomes a little difficult at times). It is less
  22. often seen in our routers, since we have alot more CPU horsepower to exhaust
  23. before you would see such a situation. But then there are usually 3 to 5 other
  24. protocols running at the same time as AppleTalk...
  25.  
  26. It is also possible that collisions can take out RTMP update packets after
  27. they have been sent by the router. This is somewhat less likely.
  28.  
  29. >My question comes up because if I sit at the console of the Novell print
  30. >server and watch the RTMP table, the next hop route to any given IP site is
  31. >doing a 'musical chair routine' among the 30 some FastPaths.  Every 10
  32. >seconds or some the next hop changes nodes on the ethertalk segment!
  33.  
  34. Well, this is something of an open area in the AppleTalk end-node design.
  35. Implementors who follow "Inside AppleTalk" to the letter will have their
  36. designated router possibly switch with every incoming RTMP packet. Please
  37. refer to pp. 5-18 and 5-19 in "Inside AppleTalk", 2nd. Ed.
  38.  
  39. Some would say that this is a nuisance in AppleTalk, that it confuses the
  40. issue of trying to figure out where your traffic is going and why. These folks
  41. tend to come from the IP world, where you either tell a Unix host to
  42. (statically) designate a default route to a router for all traffic or you are
  43. running a routing protocol which tends to "lock on" to a path.
  44.  
  45. So there are some AppleTalk end-node implementations which tend to stick with
  46. the first router they hear as the value for A-ROUTER until they quit hearing
  47. said router, at which time they pick another router on the cable.
  48.  
  49. Then there is the flip side of the coin: by switching the value for A-ROUTER
  50. with every update, you effect a sort of "load sharing" between the routers
  51. present on a cable.
  52.  
  53. Which is better? I'm sure we can find arguments in favor of both.
  54.  
  55. dsa
  56.  
  57.