Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] Uiflood ss

Expand Messages
  • James Ewen
    ... Okay, back at a real keyboard, and I see that this discussion has gone off the rails... UIFLOOD and UITRACE are routines that were first implemented in the
    Message 1 of 12 , Jan 2, 2011
    • 0 Attachment
      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:
      >> 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?

      Okay, back at a real keyboard, and I see that this discussion has gone
      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:
      > (UITRACE = WIDE)

      The actual command line would look like

      WIDE being the base alias, and the 30 being the anti-dupe time limit.

      > WIDE1-1,WIDE2-2 is been digipeated as:
      > DIGI1*,WIDE2-2
      > DIGI1,DIGI2*,WIDE2-1
      > DIGI1,DIGI2,DIGI3*

      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:
      > (UIFLOOD = SS )

      Not really a non-traceable network, but more accurately a partially
      traceable network.

      The actual command line would look like

      UIFLOOD SS,30,ID
      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:
      > DIGI1*,SS2-2
      > DIGI2*,SS2-1
      > DIGI3*

      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
      those routines.

      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
      digipeater owners.

      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)
    Your message has been successfully submitted and would be delivered to recipients shortly.