Re: [aprsisce] -IS Msg Retries & IS-Server fix (Dev: 2011/10/27 06:40)
- On 10/27/2011 12:08 PM, Bob Bruninga wrote:
>Actually, that's what I thought which is why I didn't bother filtering
>> 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?
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!