AGTEK R & D Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Agtek Tracker Proxy Server ======

A server was created to support capturing tracks from the new CalAmp Trackers. These trackers use a UDP based protocol to send data to the server.  Adding this capability to the existing Access server was determined to be risky at best and may not have even been possible.  A dedicated server was created which acts as a proxy server for getting the track data to the Access Server.  When track data is received it is captured and forwarded to Access using the existing Access track protocol.  The new server is called the Tracker Proxy Server.

===== Architecture =====

The trackers are set up to capture GPS points every second.  After one minute the tracker sends the captured points to the server.  The messages come in one point at a time identified by the tracker's ESN number.  

A mechanism had to be build which looks up the ESN numbers in order to route the tracks to the correct company and project in Access.  Rather than building a separate table or database it was decided to extend the existing Access Sql database and give the Tracker Proxy Server direct access to that database.  A new Tracker table was added to the Access Sql database and some additional API capabilities were added to Access to maintain the new Tracker table.  The ability to add new trackers assigning them to a company and a project, as well as updating existing trackers.

So the Tracker Proxy Server gets a message from a tracker.  It then looks up the tracker using it's ESN number using the the Tracker table in the Access Sql database.  Now it has the company and project to assign the tracks to.  Access requires user's to login to gain access to services.  The old Android based trackers used a special user tracker-<Company Id> to achieve this.  To avoid confusion and issues a new user is required to support the CalAmp trackers, dcs-tracker-<Company Id>.  We now have the information required to login to Access and send the tracks using the Access API's.  

==== Main Loop ====

The Tracker Proxy Server opens a UDP socket on port 20500 and listens for messages.  Currently it was decided to avoid authentication since we are only responding to a very specifically formatted messages. The message header is a single byte (0x83) followed by the length of the mobile id (ESN) then the ESN.  Next there is a mobile id type, service type, and message type.  The only message type we currently care about is a mini-report (0x0A).  If anything is misplaced in this sequence the message is ignored.

If we have a valid mini-report message we will grab the needed data (Time, Latitude, Longitude, Battery Voltage).

==== Tracker Class ====

For each unique ESN seen by the Tracker Proxy Server a **Tracker** object is created manage the tracker's data. The purpose of the **Tracker** class is capturing the incoming track data and periodically sending on to the the Access server.  To achieve this the **Tracker** class has a **PositionBuffer** class which actually houses the track positions.  The **PositionBuffer** class captures the time, latitude, longitude, and battery percent in a memory based buffer as well as directs the data to a file on disk for safe keeping in case something goes wrong.  Once the **Tracker** class has captured a set number of points it will send the **PositionBuffer** to the Access Server.

A global **ThreadPool** is used by the **Tracker** objects to forward the PositionBuffers to the Access server. When the **Tracker** object determines it is time to send it's position data to the server it will add a task to the ThreadPool using it's **_drain_buffer** method and active **PositionBuffer**. It then creates a new **PositionBuffer** and continues receiving points from it's tracker.

==== _drain_buffer ====

Drain buffer is a private method in the **Tracker** class which is used to send the Tracker's PositionBuffer to the Access server.  It first gets the company and project that the tracker is assigned to from the Access database using the **_get_company_and_project** method.  Next it connects and authenticates with the Access server using the **_connect_and_auth** method.  Once connected it will setup the buffer for sending and send the buffer to the Access server using the **_setup_buffer**l method.  If there is an alternate company and project a second call to **_setup_buffer**j will forward the tracks to the alternate location on the Access server.

If everything is successful the **PositionBuffer** is emptied and destroyed.  If there are any issues the backup file maintained by the PositionBuffer class is renamed from .dat to .sav.  The PositonBuffer is still destroyed and the backup data is resent at a later time.

===== Monitor Threads =====

There are three threads which are used to monitor different things for the Tracker Proxy Server.  The are **RecoverTracks**, **TrackerMonitor**, and **MessageCounter**.  These thread are kicked off when the server starts and wake up periodically to do their work.

==== RecoverTracks ====

This thread keeps an eye on the **PositionBuffer** backup directory looking for files with a .sav extension which indicates problems.  To have a file with a .sav extension the **_drain_buffer** method registered a problem when it last attempted to send it's **PositionBuffer** to the Access server.  If **RecoverTracks** sees these .sav files it will iterate through them creating it's own **Tracker** objects to attempt to resend the saved tracks to the Access server.  **RecoverTracks** maintains it's own list of Trackers separate from the main loops list of tracker for this task.  It will load the points from the files into the appropriate Tracker objects then tell the Tracker.  The Tracker works as usual attempting to send it's data to the Access server.  The difference between the Trackers in the main loop and these Trackers is that once all the files are sent the Trackers are destroyed.

==== TrackerMonitor ====

**TrackerMonitor** is used to monitor the trackers for the main loop.  Periodically it iterates through the list of trackers telling the **Tracker** to set an incoming points flag to false.  If the Tracker gets more points before the next run of **TrackerMonitor** the incoming points flag will be reset to true.  The next time through if the flag is still false it indicates no points are coming in for that **Tracker**.  **TrackerMonitor** will tell the **Tracker** to send any remaining points to the Access server and destroy the **Tracker**. 

==== MessageCounter ====

This thread prints to the log the number of messages received by the Tracker Proxy Server every minute.
AGTEK R & D Wiki

User Tools

Site Tools

Page Tools
