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

Re: [aprsisce] -IS Msg Retries & IS-Server fix (Dev: 2011/10/27 06:40)

Expand Messages
  • Lynn W Deffenbaugh (Mr)
    ... Actually, that s what I thought which is why I didn t bother filtering out the earlier retries. But what I ve discovered is the following (leading numbers
    Message 1 of 3 , Oct 27, 2011
    • 0 Attachment
      On 10/27/2011 12:08 PM, Bob Bruninga wrote:
      >> This should improve retries through remote IGates as well!
      > I figured the extra copies don't hurt anything on the APRS-IS, thougth I
      > think you are doing other things with them?

      Actually, that's what I thought which is why I didn't bother filtering
      out the earlier retries. But what I've discovered is the following
      (leading numbers are seconds after the message was initiated on the +8
      +16 +8 +32 +64 +128 scale):

      T+0 - IS passes, IS dupe detect set to +30
      T+8 - IS dupe detect reset to +38, not passed
      T+24 - IS dupe detect reset to +54, not passed
      T+32 - IS dupe detect reset to +62, NOT passed!
      T+64 - IS dupe detect reset to +94, PASSED
      T+128 -IS dupe detect long not an issue, PASSED
      T+256 (total elapsed), last retry, PASSED

      The big surprise to me was that the transmission at +32 was DROPPED due
      to the -IS dupe detect even though it was >30 seconds after the FIRST
      transmission. It seems that it needs to be >30 seconds after the MOST
      RECENT transmission into -IS. This meant that the first ACTUAL retry to
      be delivered through APRS-IS (potentially to the remote IGate serving
      the message recipient) was actually at the +64 second point (+8+16+8+32)
      or longer than a minute after the first transmission.

      So the new logic actually suppresses the +8 and +16 -IS retries inside
      APRSISCE/32 so that the second +8 (total +32) meets the needs of the
      server's >30 second dupe filter.

      Oh, and if the recipient is not thought to be on the local RF (not heard
      "recently" "local"), the first set of retries are sent only via -IS. If
      a packet is received from the recipient while the retries are happening
      (Message on Heard from page 10 of aprs101.pdf), the next retry will
      include an RF transmission. Also, if the entire sequence expires
      without receiving an ack, and the station is heard from later, then the
      entire sequence is retriggered ONCE via BOTH interfaces unless forced to
      retry again even later by the message originator.

      So, with APRSISCE/32 you can queue a message to a completely unknown
      station (or one that just cleared), and the first set of retries will
      happen and then the message will lie dormant. When/if a packet is
      received from that stations, all of the queued (FIFO) messages will be
      delivered sequentially with the requisite acks in between. If no acks
      are received on the retrigger, then the messages will ONLY be sent if
      the originator asks them to be retried again later. No pending messages
      being transmitted days/weeks/months later when someone restarts
      APRSISCE/32 after a period of dormancy.

      > You wrote it twice as 8+16+8... did you mean 8+16+32?

      Nope, I meant what I wrote as I'm striking a balance between the RF and
      the -IS needs. The intent is for the second +8 to drop a retry in just
      after the 30 second -IS dupe filter expires. I could just as easily
      have done +8 +12 +16 +32 +64 +128 to drop the -IS retry at 36 seconds,
      but what's the real difference? Same number of retries, just that the
      spacing is a bit different than +8 +16 +8 +32 +64 +128.

      Of course, a received ack anywhere in the sequence will drop all future
      retransmissions, so it's only in marginal (or non) coverage that the
      entire sequence plays through.

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      PS. Hopefully this is documented decently well at
      http://aprsisce.wikidot.com/message-retries which even credits you, Bob,
      with the decaying retry algorithm!
    Your message has been successfully submitted and would be delivered to recipients shortly.