Technical background on the SARTrack Database system
This document is work in progress, please come back later for the full thing...
So how does the SARTrack Database Server actually work?
Well, it is written from the ground up, and does not look like anything you find anywhere else in the world.
And
the reason for this is, that the Database Server uses a 'Push' system,
to immediately distribute incoming Live data to all connected Clients,
some of which are Database Servers themselves, and these also
distribute the data to their connected Clients.
On
top of that, all data transmited via the TCP / Internet connection is
very compact, which makes it possible to send the data over
low-bandwidth links, like Mobile Broadband and Satellite connections.
None of this was possible using 'standard' database systems (and I wasted 9 months trying this).
The
disadvantage of the system is, that both the Database Server 'tables'
and the SARTrack Client 'tables' must stay compatible. As a result, it
is sometimes required (but not always) that both all Database Servers
and all Clients are updated at the same time to the same (latest)
version. Most of the time it can be done with some flexibility,
where older Clients will still work okay, but it does not always work
out.
Still, the advantages way well up against this disadvantage.
So, how does it work, step by step?
Step
one: A Client connects to a Database Server, on TCP port 8050. After
TCP connection, its transmits the following information to the Server:
Its Callsign (A special ID for that computer only), a Login and
Password, and the 'GroupID'.
The GroupID is a number which separates all traffic on the Database Server from all other traffic with a different GroupID.
The Callsign must a unique, and is used to be able to transmit and receive data from this specific computer.
The Login and Password, when accepted, will set the Access Level for the person logging in.
Once
the Login is accepted, the Database Server will send a record to the
Client indicating, amongst other things, the name of the Active Operation.
It
will also send the current Date and Time to the Client (the Timestamp).
The Client will save the ServerTimeOffset, which is the difference
between the PC time and the Server time.
From
this moment on, all traffic between the Client and the Server is based
on the Server Date and Time, NOT on the PC Date and Time, and this includes all Log entries, Messages etc.
If the time difference is to big, an error message will appear.
The Client then requests a full Update of ALL data in the Active Operation.
The
Server will compile all Databases in a single Stream, and transmit
this in one go over the TCP network. Because of this, it will arrive
very fast.
'All Databases' in this case mean the many different
Database Structures build into the Server (and the Client!) like:
DTBUsers, Stations, Objects, Messages, MissingPersons,
OperationPeriods, etc, etc.
Once the Client has received this first Stream, it is completely up-to-date with the entire Active Operation.
From
this moment on, the Server will Update and transmit all incoming data
to all connected Clients. The Clients will only accept data with a
Timestamp which is later than the timestamp of the internal record(s).
When
the connection between the Client and Server is broken, the Client will
mark the disconnect time, and after re-connect, it will request an
Update of ALL databases, but only from the moment the connection was
lost.
If the Client is a Local Database Server, in which case
the Server is an "Internet based Server", a two-way SYNC will occur,
first on initial connect (Full Update, but only if not already
available) and after a connect failure, the SYNC will be based on the
previous Disconnect time.
After the SYNC between two Database Servers, they will also Update any new data to their own connected Clients.
MORE COMING LATER.
Bart Kindt
CEO, SARTrack developer