Re: [aprsisce] Uiflood ss
- On Sun, Jan 2, 2011 at 2:28 AM, Kai Günter Brandt <kai.brandt@...> wrote:
> On 01/02/2011 03:24 AM, Lynn W Deffenbaugh (Mr) wrote:Okay, back at a real keyboard, and I see that this discussion has gone
>> Being a non ??? user, what does UIFLOOD actually DO? Is it a digipeater
>> configuration? A Beacon path configuration? If the former, what
>> triggers it and what does it transmit when triggered?
off the rails...
UIFLOOD and UITRACE are routines that were first implemented in the
Kantronics line of TNCs. They were the first "smart" digipeating
routines designed to stop packets from ping-ponging between
digipeaters. As such, all subsequent implementations of these routines
had to be designed to fit within the design parameters of the
> i.e in a tracable WIDEn-N network:The actual command line would look like
> (UITRACE = WIDE)
WIDE being the base alias, and the 30 being the anti-dupe time limit.
> WIDE1-1,WIDE2-2 is been digipeated as:Kai is close above, but there are a few errors:
Significant because the used up path is retained, and shown with the
has-been-digipeated flag on it. UITRACE inserts each digipeater
callsign immediately before the current path. On the last hop, the
callsign is inserted and the used up path is marked as used.
> In a non tracable network:Not really a non-traceable network, but more accurately a partially
> (UIFLOOD = SS )
The actual command line would look like
SS being the base alias, and the 30 being the anti-dupe time limit,
and ID enabling the callsign insertion. There's also the option to use
NOID, where the digipeater callsign was never inserted.
> SS1-1,SS2-2 is been digipeated as:Again, not quite right...
> Using UIFLOOD it's possible for a packet to go in loop.UIFLOOD and UITRACE both do a checksum hash over the destination and
packet body characters, and retain that for the duration of the
anti-dupe timer. Both are equally capable of keeping the packets from
looping. Only a packet that is delivered back to a digipeater that has
handled that packet AFTER the dupe timer has expired will get handled
> You don't see the path where your packet originated only the last.In the two part hop request examples above, this is a little obscured...
(UITRACE = WIDE)
Using a path of WIDE3-3:
(UIFLOOD = SS )
Using a path of SS3-3:
UIFLOOD keeps overwriting the last hop callsign as the SSn-N is used
up, whereas UITRACE keeps inserting callsigns.
Now, there have been subsequent implementations of routines that work
in a manner similar to the Kantronics line. There are also software
based digipeaters that work in a manner similar to the Kantronics
routines. The examples Kai showed in his examples might possibly be
based on his observations of the operational characteristics of one of
The way the existing APRS new-paradigm concept was developed, was
based upon the operational characteristics of the Kantronics hardware.
It was also designed based on having the UIFLOOD and UITRACE routines
enabled using the settings I have indicated above.
There are many ways to screw the settings up, and as a result many
ways to have the results get mangled. I have seen software rules
written that would result in the output that Kai describes, but that
does not follow the original design, and implementation.
Waaaaaay back in the old days, when there used to exist WIDEn-N and
TRACEn-N digipeating, people would routinely use WIDEn-N as their hop
request with values up to 7 hops. TRACEn-N was reserved for special
occasions, such as when you wanted to check out just how many hops you
could get your packet to go. TRACEn-N was looked upon as being
wasteful, as each digipeater hop added another 7 bytes to the length
of the packet.
On the WIDEn-N front there was the huge ID/NOID debate going on as well.
With the new-paradigm, things got switched up... UITRACE now used the
WIDE alias, which made keeping track of which digipeaters handled the
packets the default. Also about this time, APRS networks were starting
to mature, and i-gates were getting more plentiful. People started
implementing traps to keep regular usage of large hop requests from
clogging the networks. Traps limited WIDEn-N usage to 3, 2 or even in
some cases 1 hop requests.
With WIDEn-N being implemented in the UITRACE routine, this left the
UIFLOOD routine unused, hence the SS concept. UIFLOOD now became the
way to move packets over a large area, but that area could have
physical boundaries. By having each state assigned a different SS
value, one would be able to use a large hop count, but not worry about
it propagating beyond the bounds of the state. This would mean that a
station on one side of the state could use 7 hops, ensuring that the
packet propagates across the state, but never enters into the
neighboring state right next door.
These concepts were chosen based upon the limitations inherent in the
KPC-3 line. This is going to continue to be a limitation until someone
can replace the thousands of KPC-3 units sitting on mountaintops,
tower sites, and various and sundry locations, with fancier hardware
and do it all for free, and with no work required on the part of the
If a rule based digipeater were to insert callsigns rather than
overwrite, it would not cause any degradation to the operation of the
APRS network, but for those of us who monitor the health and operation
of the APRS network by observing the paths used by packets as they
traverse the RF network, it can get very confusing. You can't really
tell which digipeaters are running which routines, and whether things
are working properly or not.
To play nicely and work in a manner identical to the way the
Kantronics line implemented the concepts, one needs to be able to
insert, or overwrite the digipeater callsign into the packet.
And that Ladies and Gentlemen was a brief history of APRS digipeating... 8)