LiveConnect - low latency transport mechanism with MQTT for iOS
What is LiveConnect?
LiveConnect is an in house messaging platform designed for fast, efficient, power sensitive and reliable data movement to and from connected nodes. A node can be any client i.e web, iOS, Android and even backend. LiveConnect is brewed with at-most care for performance and energy consumption on our customers smartphones. In this blog we will be focusing on the iOS client of LiveConnect.
You can checkout this blog for early use cases and backend changes of LiveConnect.
Why LiveConnect?
There are many use cases in client which demands client polling like:
- Order status for pharmacy delivery
- Consultation status for tele-consultation
- Appointment status for hospital services
- Nudging users with various product offers etc...
LiveConnect helps us with circumventing polling.
Considerations for an ideal Messaging Platform
There are many considerations and tradeoffs we went through to pick an ideal messaging platform and are as follows:
- Connection lifetime on client - it should be throughout the runtime of an App
- Events vs Messages - shall support the payload size large enough to support the transfer of the entire message
- Uni-directional vs Bi-directional - should support bi-directional data transfer
- Network conditions - since we are operating at remote areas of Indonesia with flaky network conditions, we should maintain low latency while ensuring seamless connection/reconnection.
- Power Consumption - ensure power consumption is as less as possible (< 5% per hour).
Many protocols defines a messaging platform and since our technical decisions affects millions of our users, we always weigh the pros and cons of our decisions and always choose what is better for our customers.
Comparison of Messaging Protocols
| Evaluation Parameter | MQTT | Web Socket | Winner |
|---|---|---|---|
| Connection/ Reconnection Overhead |
Handshake over TCP | Handshake over HTTP and thus extra roundtrips | MQTT |
| Bandwidth and Transport Latency | overhead < 3 bytes | Handle data transfers as Frames, and each frame have additional 4-12 bytes of data about the payload, there can be multiple frames per message | MQTT |
| Reliable and Guaranteed Delivery | Ensures this with multiple QoS levels | NA | MQTT |
| Power Consumption | Low | Low - Medium | MQTT |
| Scalability | Not horizontally scalable | Horizontally scalable | WebSocket MQTT needs a clustered approach to scale |
| Security | TLS | TLS | BOTH |
| Support for all client platforms Android, iOS, and Web |
Vanilla MQTT for Android and iOS MQTT over WebSockets for browsers (as they don't allow TCP connection) |
Can be run on all Client platforms | BOTH |
| Design Philosophy | BOTH | ||
| Industry Usage | Facebook Messenger, Qiscus, and AppLozic | SendBird, Twilio | NA |
| Compliance with Operators | Even though question arises over supporting of persistent connection by network operators, we can safely assume that it works, keeping the current Qiscus implementation is running on the same | NA | NA |
It is more evident with the above table that we have chosen MQTT as the messaging platform for Halodoc.
On iOS system we have many third party libraries which provides MQTT implementation.
Comparison of MQTT libraries in iOS
| Evaluation Parameter | CocoaMQTT | MQTT Client Framework |
|---|---|---|
| Latest Supported Protocol version | 3.1.1 | 3.1.1 |
| Programming language | Swift | Objective C |
| Disk caching | Yes | Yes |
| Power Consumption | Low | Low - Medium |
| SSL / TLS | Yes | Yes |
| Support of all QoS | Yes | Yes |
| Community Support | Good | Good but subsiding |
| Vendors using | AppLozic, Hotstar | Qiscus |
| Lib size | ~2MB | ~3MB |
We chose CocoaMQTT as its a well known library with good community support and leveraging latest programming language i.e Swift.
We always evaluate libraries against common performance pitfalls by Profiling using Xcode Instruments and we considered the following metrics:
- Network - thread used, how frequently they make API calls
- Memory - verify in-memory cache, data storage etc...
- Energy - power consumption metrics
- CPU - any performance hits
We evaluated CocoaMQTT against network and Energy profiling and the results are as follows:
- Network and Energy Profiling for
ConnectandSubscribingto a topic
2. Network and Energy Profiling for KeepAlive pings every 60 secs
3. Network and Energy Profiling for MQTT Publish / Receive messages
From the above observation, it's quite evident that power consumption and network bandwidth usage is quite low, hence Halodoc uses CocoaMQTT as the messaging protocol.
After we evaluated different messaging protocols and libraries, its time for implementation.
LiveConnect Architecture:
Our client architecture is designed with certain goals and are follows:
- Protocol agnostic (can be MQTT, WebSocket)
- Solution provider agnostic (MQTT Paho client, OkHttp WebSocket, etc)
- Multiple instances of connection might co-exist
- Easy to replace solution providers
The High level components for the architecture are as follows:
- LiveConnect: A façade which provides interface making client agnostic to messaging protocols and libraries.
- LiveConnectClient: Maintains multiple messaging protocol clients.
- WebSocket: A web socket protocol implemented using NSURLSession (Currently out of scope).
- Mqtt: An MQTT protocol implementation using either CocoaMQTT currently. It can be easily switched with any other library.
Open Source Contribution from Halodoc:
CocoaMQTT is the best library however it lacked automatic retries upon connection lost. Halodoc engineering is one of the tech giants who believe in open source contribution. Hence, we added the ability for automatic retries with exponential back off i.e the upon connection lost the client tries to reconnect with a configurable start value. By increasing exponentially until we get a value which is nearest to max_configurable value and we will keep re-connecting at this interval. https://github.com/emqx/CocoaMQTT/pull/290
We also faced many crashes in CocoaMQTT related to over-commits with DisptachSourceTimer. This time we as an open source contributor provided the implementation and it was accepted by CocoaMQTT. https://github.com/emqx/CocoaMQTT/pull/295
Summary
In this post, we discussed the R&D process involved while building LiveConnect with the capabilities of MQTT to enable bi-directional reliable communication between the Halodoc app and our backend infrastructure. In the blog we covered what all parameters to be considered when building a system for millions of users, how we can leverage platform capabilities like Instruments which helps us with choosing the right tool and how we can contributed to open source.
Join Us
We are always looking out for top engineering talent across all roles for our tech team. If challenging problems that drive big impact enthral you, do reach out to us at careers.india@halodoc.com
About Halodoc
Halodoc is the number 1 all around Healthcare application in Indonesia. Our mission is to simplify and bring quality healthcare across Indonesia, from Sabang to Merauke. We connect 20,000+ doctors with patients in need through our Tele-consultation service. We partner with 3500+ pharmacies in 100+ cities to bring medicine to your doorstep. We've also partnered with Indonesia's largest lab provider to provide lab home services, and to top it off we have recently launched a premium appointment service that partners with 500+ hospitals that allow patients to book a doctor appointment inside our application. We are extremely fortunate to be trusted by our investors, such as the Bill & Melinda Gates Foundation, Singtel, UOB Ventures, Allianz, GoJek and many more. We recently closed our Series B round and In total have raised USD$100million for our mission. Our team works tirelessly to make sure that we create the best healthcare solution personalised for all of our patient's needs, and are continuously on a path to simplify healthcare for Indonesia.