[aprssig] UIDIGI and the New Paradigm - WARNING - LONG!
Robert Bruninga
bruninga at usna.edu
Thu Apr 7 09:31:06 EDT 2005
Ron,
What an excellent assessment of UIDIGI ROM support
for the New n-N Paradigm. Great work!
I can think of two comments:
1) One of the issues you raise does not appear to be
unique to the new Paradigm but may just be a bug no one
has noticed before. From what you wrote, it appears to me
that a UIDIGI ROM counts down the WIDEn-N algoirthm
differently than any other application and adds an extra
digi hop on the end of every such use. This might explain
why you get an extra hop.
What we expect from WIDEn-N:
Send WIDE2-2: then WIDE2-1, then WIDE2*
What UIDIGI appears to be doing is:
Send WIDE2-2: then WIDE2-1, then WIDE2, then WIDE2*
Appearing to imply that UIDIGI ROMS do not set the
*has-been-digipeated-bit* when 2-0 has been reached,
but only does it on the NEXT additional digipeat. Thus,
all along, UIDIG ROMS have been adding an additional
hop to all WIDEn-N paths. So this bug should not be
attributed to the New n-N paradigm per se.
2) The inability to not-trap out *intentional* abusive behavior
is not a failing of the New n-N Paradigm. No one is traping
them out now, so the fact that we can trap out unintentional
mistakes with the New n-N Paradigm is only a plus. No
other stand-alone digi can trap out all possible intentional
abusive paths either. So again, this is not considered a
fault of the UIDIGI ROM
3) There is no need to worry about the *unintentional* bad
path combinations where N does not equal "n" anyway,
because if ALL digis simply trap out the 4-4, 5-5, 6-6, 7-7
at the point of entry, then no other digi will see the other
combinations in the first place. They wont get into the
system.
4) Thus the only failing you found left is the fact that you
have to use WIDE1-1, as an alias instead of letting the
WIDEn-N algorithm handle it. Again, this is not any problem
at all, beacuse (I think) the UIDIGI ROM uses one overall
dupe-elimination algorithm no matter what digi method was
used. Thus the UIDIGI ROM digi does perfect dupe
elimination on all packets and so having to use WIDE1-1
as an alias is not a problem at all.
Thus, in my accounting, of all the issues you raised, there
is nothing wrong with using a UIDIGI ROM to support the
New n-N Paradigm (with WIDE1-1 as an alias)... And secondly
there are two things we ask the author to fix in his next release:
1) Allow the sysop to set a MAX-N limit
2) Fix the beacon algorithm so that the UIDIGI ROM beacons
can go out locally more often and via 1 hop and 2 hops
less and less often
Did I miss anything or missinterpret anything?
Bob, WB4APR
>>> Ron Stordahl <ron.stordahl at digikey.com> 4/7/05 12:05:42 AM >>>
Testing this evening produced some unexpected results and the
conclusion
that the New Paradigm cannot be fully implemented in UIDIGI as it
currently exists. Skip to the end for a summary.
Wishing to allow only these paths to be fully functional:
WIDE1-1 (for 1 hop)
WIDE2-1 (for 1 hop) - but it's really 2 hops.
WIDE2-2 (for 2 hops)
WIDE1-1,WIDE2-1 (for 2 hops)
WIDE1-1,WIDE2-2 (for 3 hops)
I set the relevant parms thus on the nearby UIDIGI and surrounding
UIDIGI's that can hear the nearby UIDIGI:
UIDigi WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN
UIDCsb 1 (enable callsign substitution for UIDigi calls)
UIFlood MN (call to be used in the flood algorithm)
UIFLDfl 0 (make call substitution after last 'floodcall' digi'd)
UITrace WIDE (call to be used in the trace algorithm)
UITRFl 0 (make call substitution after last 'tracecall' digi'd)
Then I generated from a TinyTrak3 packets with these paths:
WIDE1-1 (it was digi'd once as expected) - shown in the dig'd packet
as
N5IN-2*,WIDE1 and not digi'd further. I can hear 1 level out and did
not hear another digi repeat the packet.
WIDE2-1 First as N5IN-2*,WIDE2, and a second time as N5IN-2,WIDE2* I
had expected it to act just as WIDE1-1, but in fact it acts as WIDE2-2
(in regards to the number of hops allowed).
WIDE2-2 - Shown in the first digi'd packet as N5IN-2*,WIDE2-1 and in
the
second as N5IN-2,WB0WTI-11*,WIDE2. If it was digi'd further I have no
way to tell as I can't hear further out. However I would be willing to
bet that it is in fact limited to 2 hops as it should be.
WIDE3-3 (it was digi'd once only as expected) - shown in the first
digi'd packet as N5IN-2* with nothing following. There were no
additional hops, and I could hear them if they existed.
WIDE3-2 Shown in the first digi'd packet as N5IN-2*,WIDE3-1, in the
second as N5IN-2,WB0WTI-11*,WIDE3 and I suspect there is a 3rd hop as
N5IN-2,WB0WTI-11*,WIDE3*, although it would be too far out for me to
hear. I draw that conclusion based upon what I could here in the case
of
WIDE2-1, where there were 2 hops. And if this is so I suspect that
WIDE3-1 will also produce 3 hops.
Now for combined paths:
WIDE1-1,WIDE1-1. The first digi'd packet contains
N5IN-2*,WIDE1,WIDE1-1
and is not repeated by any of the surrounding digi's. I had expected a
second hop, but it did not occur.
WIDE1-1,WIDE2-1. The first digi'd packet contains
N5IN-2*,WIDE1,WIDE2-1
and is not repeated by any of the surrounding digi's. I had expected a
second hop (and maybe a 3rd) but it did not occur.
WIDE1-1,WIDE2-2. The first digi's packet contains
N5IN-2*,WIDE1,WIDE2-2
and is not repeated by any of the surrounding digi's. I had expected a
total of 3 hops, but only one occurred.
Apparently the WIDE1 is the end of the line, perhaps I should have
expected that. In order to permit these to work I had to add WIDE1-1
into the UIDIGI list thus:
UIDigi WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7,MN and I also
made this change in the surrounding UIDIGI's..
Now combined paths again with this new setting:
WIDE1-1,WIDE1-1 The first digi'd packet contains N5IN-2*,WIDE1-1 while
the second and final digi'd packet contains N5IN-2,WB0WTI-10*
WIDE1-1,WIDE2-1 The first digi'd packet contains N5IN-2*,WIDE2-1, the
second N5IN-2,WB0WTI-10*, and I suspect a third
N5IN-2,WB0WTI-10,WIDE2*
WIDE1-1,WIDE2-2 The first digi'd packet contains N5IN-2*,WIDE2-2, the
second N5IN-2,WB0WTI-10*,WIDE2-1 and I suspect a third
N5IN-2,WB0WTI-10,WIDE2*
Finally approaching some conclusions:
You can't shoehorn the New Paradigm into the UIDIGI, but you can get
part way there. a UID of
WIDE1-1,WIDE3-3,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 works thus:
WIDE1-1,WIDE1-1 (works as expected producing 2 hops)
WIDE1-1,WIDE2-1 (produces 3 hops and not 2 as hoped)
WIDE1-1,WIDE2-2 (works as expected producing 3 hops)
With RELAY added to UID (now both RELAY and WIDE1-1 are in UID)
RELAY,WIDE1-1 works as WIDE1-1,WIDE1-1 (2 hops)
RELAY,WIDE2-1 works as WIDE1-1,WIDE2-1 (3 hops not 2 as hoped)
RELAY,WIDE2-2 works as WIDE1-1,WIDE2-2 (3 hops)
WIDEn-N for n=N and n>2 but < 8 all terminate with a single hop, thus:
WIDE1-1,WIDE4-4 allows just 2 hops.
Unfortunately WIDE5-4 produces 5 hops (it is not trapped).
For WideN-M where M<N the trapping fails.
You will also note that in order to substitute WIDE1-1 for RELAY it is
necessary to place WIDE1-1 in the UID list (otherwise serious problems
result which are detailed above). By doing so I believe RELAY and
WIDE1-1 act identically, the latter not producing any less QRM.
=============================================================
1) If you wish to support both RELAY and WIDE1-1 (in the UID list, and
thus treated differently than WideN-n in that it is no longer a UIFlood
or UITrace token) then both of these must be placed in the UID list.
By
doing so you will have space remaining for just additional 6 tokens.
If
you are in a 3 hop area then the UID list would have to contain:
RELAY,WIDE1-1,WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 plus 2 more tokens. To
fully implement restrictions against excessive paths you would need to
add WIDE4-3,WIDE4-2,WIDE4-1,WIDE5-4, etc which totals 18 tokens. There
is no room to do this. And the result is inconsistent as while it
allows a path of WIDE3-3, it also allows a path of RELAY,WIDE3-3 or
WIDE1-1,WIDE3-3 which is 4 hops. Someone who wishes to break the rules
can use a path of WIDE7-6 and get 7 hops. Also paths such as
RELAY,RELAY,RELAY,RELAY,RELAY will be supported.
2) If you wish to abandon RELAY and WIDE1-1 in its special application
as a twin to RELAY, then the UID list for a 3 hop area will contain
just
WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 giving you space for 4 additional
tokens
out of the 18 additional spaces you would need to fully implement. In
this implementation the following paths will be permitted:
WIDE1-1 (1 hop)
WIDE2-2 (2 hops)
WIDE3-3 (3 hops)
but you will be able to block just 4 our of the remaining 18 paths such
as WIDE7-6 which will produce 7 hops.
3) If you wish to retain RELAY, but not include the special
application
of WIDE1-1, you gain one additional slot in the UID list.
Conclusion: The New Paradigm can only be poorly supported by UIDIGI at
present. Abandoning RELAY (and/or the special use of WIDE1-1 as an
equivalence for RELAY) simplifies things only slightly. While I have
no
means to test the KPC3+, I suspect it may the same shortcomings as
UIDIGI.
Assuming users are well behaved it may be worthwhile to implement, but
if users were well behaved we wouldn't need to place limits upon them
as
intended by the New Paradigm in the first place.
I had hoped for better.
Only Marco Savegnago IW3FQG, the author of UIDGI, is in a position to
fully solve this problem by allowing a simple hop limit to be enforced
in the code irrespective of what paths a user tries.
Ron, N5IN
_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
More information about the aprssig
mailing list