multiple routes

[val!ben@cs.utexas.edu (Ben Thornton)]

Doc writes:

> The problem with only caching the incoming information is, I think,
> that it relies on the OTHER guy to tell you about what path to use.
> If NOS doesn't ever iniate such checking itself of which is the best
> route, then NOS, all by its lonesome, will never update any routes. It
> will, rather, rely on real-live people trying the alternatives first.
>
> In order for NOS to be "intelligent" itself then I think that it must
> do a certain amount of "sniffing" for itself. "Flooding" sounds a bit
> strong a term for it, because I suspect that most of us most of
> the time would only have at most two reasonably plausible routes to
> any given host. A couple of pings along two paths once an hour or
> so shouldn't be a problem as far as channel usage is concerned, I
> wouldn't have thought.

  I recently had an idea along these lines.  Would it be possible to
extend RSPF to be able to recognize the "#" nodes in Netrom routing
table update broadcasts?
  The RSPF code would then scan the currently loaded netrom table
and add routes based on whether a station is preceded by the "#" in it's
alias and whether the node is in the manually preloaded arp table.
  Is this rational?  It would add no more network overhead, I wouldn't
think, than that already added by RSPF.

Ben

Ben Thornton             packet:  WD5HLS @ KB5PM
Video Associates       Internet:  ben@val.com
Austin, TX                 uucp:  ...!cs.utexas.edu!val!ben
Did Schrodinger exist? ...or was that in another universe?