LiveConnect - low latency transport mechanism with MQTT for iOS

mqtt Dec 17, 2020

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:

  1. Order status for pharmacy delivery
  2. Consultation status for tele-consultation
  3. Appointment status for hospital services
  4. 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:

  1. Connection lifetime on client - it should be throughout the runtime of an App
  2. Events vs Messages - shall support the payload size large enough to support the transfer of the entire message
  3. Uni-directional vs Bi-directional - should support bi-directional data transfer
  4. 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.
  5. 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:

  1. Network - thread used, how frequently they make API calls
  2. Memory - verify in-memory cache, data storage etc...
  3. Energy - power consumption metrics
  4. CPU - any performance hits

We evaluated CocoaMQTT against network and Energy profiling and the results are as follows:

  1. Network and Energy Profiling for Connect and Subscribing to 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:

  1. Protocol agnostic (can be MQTT, WebSocket)
  2. Solution provider agnostic (MQTT Paho client, OkHttp WebSocket, etc)
  3. Multiple instances of connection might co-exist
  4. Easy to replace solution providers

The High level components for the architecture are as follows:

High Level Design
  1. LiveConnect: A fa├žade which provides interface making client agnostic to messaging protocols and libraries.
  2. LiveConnectClient: Maintains multiple messaging protocol clients.
  3. WebSocket: A web socket protocol implemented using NSURLSession (Currently out of scope).
  4. 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.

Sachin Vas

Swift enthusiasts with 8+ years of experience in iOS.