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

[Georg Lukas]

Hi Gerhard,

* Gerhard.F5VAG <f5vag.eu at gmail.com> [2012-04-15 20:14]:
> 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.

I am really sorry for that misbehavior of APRSdroid. From my analysis,
there are currently two issues in the application causing bad behavior
on APRS:

1. the combination of SmartBeaconing and "wandering" GPS. When the
device has a really bad GPS fix, with the position moving around,
SmartBeaconing corner-pegging is triggered too often, sending position
packets at minimum intervals. I am working on a solution for this.

2. (the problem you have observed) the APRSdroid service is killed by
the Android system due to low memory, then automatically restarted after
some seconds. Unfortunately, this means that APRSdroid has to reconnect
to the server, and can not "remember" its internal state, including when
it last sent a position report. This causes it to re-send a new beacon
right after connecting. I will see how I can permanently store the last
position to prevent flooding the medium. Unfortunately, I can not do any
more to prevent the application from being killed by the OS.

> 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

This is anything but intended behavior. APRSdroid normally connects to a
server, and keeps the connection as long as it is running and has a
network connection. When the network connection is interrupted, it tries
to reconnect in 30-second intervals, which I hope is OK from a server
operator PoV. Also, after reconnecting it does _not_ automatically send
a new position report.

> 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.

You are right for simple position beaconing. However, the TCP connection
has the huge advantage of also providing APRS information _to_ the user,
which is lacking with UDP. As I already outlined, the default behavior
in APRSdroid is to keep the connection open and to display the incoming
packets to the user.

I have triangulated that individual offender and will write him a polite
off-list message to see how I can improve the situation.


Kind regards,

Georg DO1GL
-- 
APRSdroid - Open Source APRS Client for Android ++ http://aprsdroid.org/m
     ++ https://market.android.com/details?id=org.aprsdroid.app ++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20120416/18ade07e/attachment.pgp>