Order Tray | Contact Us | Home | SIG Lists

[aprssig] New n-N success in North Carolina

Wes Johnston aprs at kd4rdb.com
Sat Feb 12 15:58:14 UTC 2005

Quoting Jason Winningham <jdw at eng.uah.edu>:
> In either case the _router_ would determine how many hops the packet
> was allowed.
> if requested hop_count > max_allowed_hops
> 	hop_count = max_allowed_hops
> hop_count--
> if hop_count > 0
> 	transmit packet

I kindly disagree with this.... In this example you take my packet and alter it
at the point of entry into the network.  From there, every digi that hears my
packet would then digipeat it that max_allowed_hops.  THis is the same a 2nd
hand source routing.... let's call it proxy source routing.

Catching the maxhops would be the responsibilty of the first digi in the chain. 
Like Bob's "trap out" method it would put me (as a digi owner) in a position of
depending on other digi owners to control what my digi is subjected to.  I
strongly feel that each digi should be responsible to determine it's own

I think a better model would be to allow *each* digi along the way to decide
what was the max that *it* would digipeat.  It would either digi the packet or
not, but would not alter it for the sake of other digipeaters.

Because WideN-N nomenclature makes it difficult to explain, allow me to redefine
the n-n to x-y for a few minutes.  Consider that WIDEn-n is really WIDEx-y
(where x is the originating number of hop requests - like ttl in tcp/ip, and y
is the number of hops remaining)

if y > x then
	y=x    ' trap the lids who would like to run wide3-7 or wide7-15
end if

if x-y < max_allowed_hops then
	transmit packet
end if

> What will all this take?  A small but fundamental shift in thinking (up
> one layer in the OSI reference model), a little planning, and that
> microcontroller that's been mentioned.

You are dead-on right about this.... the thing is it could be done as an
external add-on doohicky to every kpc3 or other TNC... and for cheaper than the
price of a firmware eprom.


More information about the aprssig mailing list