[aprssig] Why Not "Gate in Vicinity"

[Lynn W. Deffenbaugh (Mr)]

I kind of thought you were mixing up concepts here and thinking that the 
30 second dupe checksuming of good digipeaters could somehow be 
stretched to cover the non-duplicate high-speed beacons from the APRS-IS 
clients.  Not likely.  It's not the place of a network transport to 
decide what's important and what's not.  It's a transport.

APRS-IS also has an inherent 30 second dupe filter just like the one 
that good digipeaters use.  This prevents the inevitable duplicates 
received by various IGates within a single RF footprint from being 
redundantly delivered throughout the APRS-IS network.  But this is an 
EXACT duplicate filter (sans path) so it doesn't help either.

The only, IMHO, truly valid and "safe" fix for too-fast beacons is to 
fix the clients that are issuing them.  The network isn't responsible, 
but the -IS to RF IGate operators are, so the software they are using 
needs to provide suitable assistance.

There's all kinds of ideas and algorithms that could be described, 
discussed, debated, and possibly discarded, but ultimately it's up to 
the IGate software authors to provide something that works.  And to 
avoid requiring a post-doctorate degree to configure it, it better be 
simple.

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

PS.  I don't know that there is a "correct term" because I don't know of 
any IGate software out there that provides any intelligent processing 
remotely similar to what we're discussing now that mobile APRS-IS 
clients are popping up like fruit flies.

On 12/23/2011 5:03 PM, Steve Noskowicz wrote:
> --- Lynn W. Deffenbaugh (Mr) wrote:
>> On 12/23/2011 10:37 AM, that Steve Noskowicz wrote:
>>>      It seems to me that having something
>> similar to the 30 second RF-RF non duplicate repeat
>> restriction added for IS to RF beacons ...
>>
>> Maybe I just don't call it what you do, but what exactly is
>> "the 30 second RF-RF non duplicate repeat
>> restriction"?  And where do you think such a
>> restriction is implemented?
> Lynn,
>
> Could be.  Perhaps it's some hold-off or such.  I just know about it.
>
> I'll elaborate a bit...
>
> I believe it is standard setup for a digi to *not* repeat (RF>RF) an identical packet if received within 30 seconds of the previous (I think to prevent flooding the channel). While testing a setup, you can't bang away forcing packets willi-nilly and see them all digipeated.  If I understand correctly, this is only for idential beacons, i.e. stopped in one place.
>
> Now, I don't think this concept is so simple. Perhaps this proposed IS->RF gating restriction would apply to either identical or 'similar beacons' from a single client or may include other types of packets if identical. I don't know.
> Since VE4HTO-14 was still moving and popping beacon posits like machine-gun fire, they won't obviously be identical.  However, an interval of 1-5 seconds can't be reasonable for any situation that I can imagine.  So the initial concept is inhibiting any _posit/beacon_ from an IS deviceif it was received within 5, 10, 15...  seconds of the previous one.
>    Now, I realize this looks like a band-aid to fix one problem and it could be, but it may help in other situations if it is agreed that rapid fire packets are not useful/desired in general.
>
> That's the concept to start.
>
>    So hope that explains it better.  Give me the correct term and I'll be smarter.  I also don't know the capabilities of Digi sw to do something like this.
>