SARTrack Logo

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.


Bart Kindt
CEO, SARTrack developer