[aprssig] distributed findu possible ?

[Matti Aarnio]

On Wed, Aug 06, 2008 at 02:03:10PM +0200, Michael Conrad wrote:
> Hi,
> 
> after reading the posts about the movement (and the monthly costs)
> of the findu servers and old idea was coming back in my mind.
> 
> At present there are some very cool APRS web applications, but most
> of them have to fight with monthly/periodically costs (bandwidth,
> hardware, administration) and some of them are unable to cover the
> expenses via donations or banner ads.
> 
> If the amount of APRS users will increase, these costs will also
> increase until the operator of an APRS web application is unable
> to provide the service.
> 
> Maybe its time to think about alternative solution using the computing
> ressources (bandwidth, memory, storage) of more than a small group of
> people. Personally I would prefer a distibuted approach, where the
> whole infrastructure is provided by a (preferably large) subset of
> all APRS users.

Mmm...  like that all my embedded APRS IGATE systems would run database
storage that can be queried from network at large ?

Regional APRS-IS nodes might do it,  but then my thinking is that APRS-IS
nodes should be memory-only processing -- embedded, but with a bit larger
memory.

A few days of _full_ network traffic in N ways queryable database, plus
actively used processed views on data do need _large_ database storages.
Plus database backups, replication, etc. fancy things.

If users are permitted to cherry-pick on what subsets they want to serve,
and are permitted to remove their machine from service pool at any time,
there will never be full global coverage, nor will there be US coverage.
(The flow is so large...)


> A distributed APRS database could work as follows:
> 
> 1. There a set of nodes, all running the same web application and a small
>    (in memory) database.   Each node is responsible for a specific
>    (dynamic) geographical area and stores APRS information related to
>    this area. (Each node is connected to APRS-IS, but requesting only
>    APRS data from a small area)

Distributed databases are known technology,  one bastard variation of theme
is in BitTorrent protocol.   Correct design and implementation is extremely
challenging, especially the part of data partitioning design -- which data
lives where, and why there ?  How many data replicas there are ?
Which sub-database is authoritative master for given subset ?  How they vote ?
How do they determine conflict resolution, and do it without admin action ?

An APRS-IS server needs around 400 MB of history databases and lookup
storages in order to recall last heard position for station X.
Why for station X ?  Somebody wants to get packets whose destionation
location is within 20 km of station X,  or want to know if a message
to station X is within igate service area, or ....

The APRS-IS needs to keep full traffic of last 30 minutes in traffic backview
buffer, plus all packets with location information for a few hours (2-3) in
history buffer - plus a few other small rarely needed databases.
Those are all for different kind of filters.

If the "dump last 30 minutes of traffic" -feature could be thrown away,
the APRS-IS server memory footprint would shrink considerably, but that
does not help the "findu"-like systems at all, they would need N gigabytes
of memory if it all should be kept on memory...  (and "N" is very much
larger than 4 ...)


> 2. If a users wants to requests the status of another station, he is
>    directed via DNS (domain name system) to a random node (the entry
>     node) of the distributed APRS database.

This is known as "DNS based load-balancing".  "www.findu.com"  returns two 
IP addresses, thus it already does this.  There is even a big-dollar industry
doing this in smartest way possible -- companies like Akamai.

> 3. After entering a call by the user the entry node dertermines the
>    responsible node and redirects the user to this node (transparently
>    to user)

User-interface runs the entire application, and is thus able to interact
with servers to locate correct database nodes ?

Sure it distributes part of the load, but networks are now carrying database
lookups in varying degrees of stupidity, and there is no guarantee that
freshest application is distributed to users, or that it works at their
machines at all.

There is the Java-school of thought.  There is the .NET-business, etc...
Java security model for web browser hits the "go to that database" idea
like a ton of wet concrete.

The idea of distributed database in itself is not wrong.  Google does it
very successfully.  They just have a large number of identical front-ends
in front of the distributed and partitioned database, said frontends do
handle access details to the database and data presentation.


> 4. The responsible node displays the APRS information (station status,
>    wx, raw data) or is able to show near APRS traffic.
> 
> If someone out there, who is willing to discuss such a mid-term solution,
> please respond to my mail.
> 
> First steps could be an analysis about the requirements (APRS messages
> per day, hits per day) and the feasibility of such a project.

I have ran test extracts of full APRS-IS feed a few times.
I recall it being 115 000 - 130 000 APRS data records per hour.
Another view:  10-11 MB/hour of network traffic.  (250 MB per 24h, etc.
plus lookup indices.)

Anyway: 30-40 APRS records per second all day around.    That begins to
make a serious challenge on database insert unless there is really smart
indexing.


> Greetings
>     Micha
> 
> PS: I think, there a lot of people, which will run a computer at home
>     to be a part of the global APRS network/infrastructure before funding
>     50 bucks for another project.

Those who run computers at home do not - on average - have any idea of what
the data center issues are for this type of service.

When database transactions are disk-io limited, and traffic exceeds what can
be pushed on the disks, then begins  a)  database optimization (and DB usage
optimization),  and  b)  data partitioning to put parts of it on separate
DB clusters...  and  c)  desperation.


BR,  Matti,  OH2MQK