[aprssig] Excessive beacons/connects by "smart" IS clients

Gerhard.F5VAG f5vag.eu at gmail.com
Sun Apr 15 17:15:41 EDT 2012


Yes, Lynn, I absolutely agree. But unfortunately my server's
log shows this behavior for some clients.

Others, which stay connected, also try to send beacons every
ten seconds or so.

I have masked the callsign of my example, because the users
probably don't know what they do. The software developers
should include some precautions.

.....
73 de Gerhard, F5VAG


On Sun, Apr 15, 2012 at 10:33 PM, Lynn W. Deffenbaugh (Mr)
<ldeffenb at homeside.to> wrote:
> There is absolutely no reason, IMHO, for connecting and disconnecting for
> each beacon.  APRSISCE/32 establishes a connection to an APRS-IS server and
> maintains that connection until an error is encountered, it goes quiet too
> long (missing heartbeats indicating a non-error-detected loss of
> connection), or the client is closed.
>
> If there's an APRS-IS client out there that is connecting, beaconing, and
> disconnecting, then I would consider that to be a busted client which needs
> to be fixed, regardless of the beacon frequency.
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
>
> On 4/15/2012 9:11 AM, Gerhard.F5VAG wrote:
>>
>> The various APRS-IS servers are exposed to an increasing number of
>> mobile TCP/IP clients which tend to send at beacon rates exceeding
>> reasonable limits. This issue will rapidly increase with the increasing
>> number of "smart" portable devices.
>>
>> In these cases aprs.fi sends the kind warning
>> "This station is transmitting packets at a high rate, which can cause
>> congestion in the APRS network.".
>> http://f5vag.eu/tmp/APRS_FI_info_FNaaa-9.html
>>
>> However, seen from the server to which the client is connected, the
>> observation
>> is much worse. In certain cases the server has to handle
>> connect/disconnect
>> cycles below ten seconds over considerable time periods:
>> http://f5vag.eu/tmp/JavServUser_FNaaa-9.html
>>
>> Many of the excessive beacons are fortunately dumped by the entry point
>> server and not forwarded to the main stream, e.g. dupes.
>>
>> In my view it is not reasonable to sent beacons with an interval of less
>> than
>> five minutes with TPC/IP connections, but to use UDP. Many T2 servers
>> provide
>> this possibility on port 8080. It drastically reduced the overhead for
>> the servers
>> and the clients by avoiding the connect/disconnect overhead.
>>
>> Even for clients using UDP the beacon interval should be limited to 30
>> seconds. I know that this limits the resolution to 0.8 km @ 100km/h
>> (0.5 miles @ 60MPH) and think this is a reasonable limitation.
>>
>> In any case, more "smart" beaconing should be used..
>>
>> Any comments?
>>
>> .....
>> 73 de Gerhard, F5VAG
>> http://f5vag.eu, france.aprs2.net
>>
>> P.S.: The callsign in the above links is certainly not real.
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig




More information about the aprssig mailing list