SSE (Server-Sent Events) implementation in Katsana V2

Katsana Version 2.0 that will be released very soon incorporates quite a number of advanced enhancements that are not seen in typical GPS tracking platforms.

A quick background into Katsana GPS Tracking platform Version 1.0

Katsana V1.0 is our first ever live GPS tracking platform that was made available to subscribers since last January 2014. The features available in version 1.0 covers the basic necessities expected of a live GPS tracking system, plus with a couple of unique Katsana-only feature adaptations.

Live network streaming options

In order to transmit live data (ie to update the location of GPS-tracked vehicles without having to refresh the browser), there are a couple of options available. In Katsana version 1.0, we are using the common Ajax Polling method / JSONP.

Apart from the rather popular Ajax Polling/JSONP method, developers may also opt to use Websockets, Flash, or Server-Sent Events to enable streaming network calls through raw TCP or UDP.

Potential bottleneck with Ajax Polling/JSONP

Now, each of the options above may have their own pros and cons. So far, we have successfully implemented Ajax Polling in Katsana version 1.0 and while we have yet to encounter much problems, we could see that as Katsana scales up in the number of vehicles tracked, and the number concurrent users that log in increases, we might encounter some serious bottlenecks in the future.

Choosing Server-Sent Events method for Katsana V2.0

Before we delve into SSE, I think it is important for us to explain Katsana’s communication medium and the background processes.

Our KAT3000 GPS tracking hardware will continuously send a ping with coordinates and other information to our data logger. Once we receive a handshake and it comes from a valid source, the raw data will then be stored onto our database. In the next processes, our servers will crunch those data and interpret the speed, coordinates, altitude, movement angle, battery level, GSM level, satellite signal quality and all the rest of the other data.

Now here is where the potential issue may appear in the future.

In Katsana version 1.0, live location update on the platform is done through Ajax polling. The problem is, Ajax polling creates some small overhead and establishes unnecessary connections. Why? Because Ajax polling is a two-way street kind of communication.

With Ajax polling:

1. Browser requests latest location.
2. Server responds, irregardless of the availability of new data.
3. Browser requests back latest location in the next ping.
4. Server still responds, whether data is available or not.

In the event that we have no new data for the request, we will send 304 Content Not Modified response. The response body will still be empty, but there is the catch of having the overhead (response header etc). Look at the picture below the see the size of each response which range from 550-575 bytes.

From the communication trail above, its obvious that we should only update the location of the vehicle only when there is new fresh data. However due to the nature of Ajax polling that continuously request for new information at certain time interval, this behavior may lead to slow response time from our servers. Plus, it could also pose a problem if the vehicle is being monitored by multiple users at the same time.

Although the size of our data is very small, the overhead in establishing the connection, processing and sending the data to the user may cause scalability problems in the future.

In short, we simply need just one-way communication (ie servers send the data directly to the users when there is new data) instead of wasting our resources on two-way street.

Here’s where SSE fits KatsanaGPS perfectly

Using Server-Sent Events, the browser simply makes an HTTP request to the server which responds with the exact data (well, prefixed with data: and the ended with /n /n. Thats it! No much overhead, no need to create multiple connections for each request, and in fact, you will just need to have one persistent connection per client.

With SSE, instead of Katsana servers responding with the whole body, we could just transmit:

data: {"data": {"latitude": "x", "longitude": "x", "speed": "x", "altitude": "x", "course": "x"}, "status": 200}

In the event that there is no fresh data, browsers will get:

data: {"data": null, "status": 304}

The 304 response code is used to mark a skipped heartbeat, which in our live monitoring platform is meant to trigger the ‘Last updated’ message. Even with the 304 response from the servers, there will not be any overhead of having additional http request as compared to our previous Ajax polling method.

Plus, the eventsource library (js/browser native) intelligently reconnects when the connection is lost. Pretty neat indeed.

Every single request is now optimized.

As a result we see a drastic reduction in term of the size of requested data, and the amount of connections created when Server-Sent Event (SSE) is implemented on Katsana Advanced GPS Tracking system.

In one sample, we continuously track a vehicle (my personal car to be exact) for 7 straight hours. The outcome speaks for itself.

We are pretty satisfied with the experiment. This reduction is drastic and goes a long way into getting Katsana ready for future expansions.