[aprssig] APRS Message Idea

[Phillip B. Pacier]

Announcements and Bulletins in UI-View do utilize a decay method, which 
is clearly outlined in the instruction manual.  With regard to general 
messaging, no, there is no decay rate, and perhaps that would be a 
useful tool for the reasons you describe below.  However, there are 
other checks and balances in UI-View to prevent flooding of message packets.

73
Phil - AD6NH

Wes Johnston wrote:

>Bob's right about this one though.... the decay is the way to go.  One of the
>things I thought was so cool about TCP/IP when I started playing packet was
>that TCP/IP would back off exponentially when attempting to deliver a packet,
>as opposed to the dumber ax.25 'fixed timing with a little randomness' method. 
>When delivering packets onto a network, with TCP/IP it would start out pretty
>agressive but back off quickly if the link turned out slow.  AX.25 on the other
>hand could send a packet over a long link, and if set aggressivly enough, would
>send the same packet again twice before the ACK got back.  Not very effecient.
>
>Also, there's another advantage to the decay.  Let's say that I send a message
>right now.  about 1 minute later, you send a message.  They collide because you
>pressed enter at the same time my station resent a copy of my message.
>
>Now in a fixed timing system where we each retry every minute, we will always
>collide.
>
>In a decay timing system, my message's next TX interval is 2 minutes from now. 
>Your's is 10 seconds from now.  We don't collide again.  The point is that even
>when our timings match up every once in a while, our interval to the next TX
>time is different and we won't collide again for a good long while.
>
>I wish more APRS clients used the decay model.
>Wes
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>  
>