A project I’m working on involves changing the messaging technology for the delivery of realtime information to train drivers using iPad. This project made me interested in the various ways to design realtime messaging plattforms for mobile clients.
Unlike realtime messaging systems for web or desktop applications, mobile applications have to deal with the additional concern of unreliable connectivity. This unreliable connectivity is more subtle than I though. Here are for instance a few points to consider
- no connectivity or poor connectivity (tunnel, etc.)
- the device my switch from 5G to WLAN
- connection breaks when app goes in the background
- Different WLAN HotSpots (Androis, iOS) result in different behavior
You need to design your application to support these use cases correctly.
Here are some aspects of the communication that you need to consider
- Does the client need to load some state upon connection?
- Have updates a TTL?
- Are messages broadcasted to several clients or unique for the clients?
- Is message loss important or not?
- Does the server need to know which clients are connected?
- Do you have firewall between client and server?
Depending on the answers to these questions, you migth decide to establish a point-to-point onnection from the device to the backend. If you want to broadcast information to several clients you need to do this yourself in this case. You will also need to manage the sate in the backend yourself. Tracking the presence of the client is trivial, since there is one connection per client. Several technologies exist for this use case:
- Server-Side Event
- HTTP Long Polling
- gRCP
- WebSocket
You might otherwise decide to rely on a messaging system with publish-subscribe. The most common protocol for mobile messaging in this case is MQTT, but there are others. With a message broker, the broker takes care to broadcast message and persist the state according to the TTL. Tracking the presence of the client can be achieve with MQTT by sending a message upon connection and using MQTT’s “Last Will Testament” upon connection loss.
There are of course more details to take care when comparing both approaches, especially around state management. For instance, how to make sure that outdated messages are ignored.
We chose the latter option (MQTT) for our project, but I’m sure we could have achieved our goal with another architecture, too.
MORE
Apprently Uber and LinkedIn rely on SSE:
://ewernli 