A tracking server that converts different device messages into usable positions and events.
This fleet management software case study begins where the device sends its own GPS report. That report reaches the server in its raw format. The platform decodes it into common position fields. From there it drives the live location view and the movement figures for the fleet. It also produces geofence events and reports. Anything unique to a given tracker stays available as an attribute.
The challenge
Devices may connect on and off, or they may send their reports out of order. Some even hold a session open without repeating their identifier. A useful tracking record depends on holding on to that identity and on judging when a buffered message is ready to process. A shorter wait also leaves a smaller window for putting those reports back in order.
What we built
Protocol decoders handle TCP, UDP and the other supported feeds. Session handling recognises each device and can deliver queued commands the next time it reports. Outgoing commands are encoded for the target protocol.
The position pipeline adds motion and distance, then engine hours and location enrichment. Event handlers spot conditions such as overspeed, ignition changes and geofence crossings. An optional segment check can catch a boundary crossed between two positions, even when neither report sits inside it. Trips, stops and summaries are available as reports and exports.
Technical approach
Frame decoders first split the incoming data into complete messages. Protocol decoders then fill the common model and store device-specific values in an attributes map.
Each device gets a short ordering buffer and a processing queue. Released messages run one at a time for that device, while other devices keep going on separate event loops. The configurable buffer sets the tradeoff between delay and the ordering window.
Filtering, enrichment and saving follow a defined handler sequence. A rejected position stops at its filter. An older reading cannot replace a newer one as the device's latest position. Updates go to the users linked to that device.
Permissions connect users and groups to the devices and geofences inside a single installation. They do not hand out separate customer databases.
Some stages keep data in memory, and forwarding can happen before the local database write. Where every report must be kept, the deployment has to make explicit choices about acknowledgement timing, retention and durable downstream delivery.
Project success
Mixed trackers can feed one reporting and event model, with no interface decoding their protocols twice. Intermittent devices can still receive queued commands once they come back. The per-device queue keeps released work in sequence, and the buffer setting makes its timing limit clear.
Technology stack
Backend
Java, Netty, Jetty, Jersey
Dependency injection and migrations
Guice, Liquibase
Supported databases
PostgreSQL, MySQL, MariaDB, SQL Server, H2
Integration protocols
REST, MQTT, AMQP
Optional messaging
Kafka, Redis, RabbitMQ
Other engagements
Recognize the pattern?
If one of these looks like your situation, the discovery call is where we find out how close.
