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.

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.

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

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 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_bufferl method. If there is an alternate company and project a second call to _setup_bufferj 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.

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.

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

This thread prints to the log the number of messages received by the Tracker Proxy Server every minute.