MQTT, the protocol behind efficiency
In Tiledesk humans and chatbots work together side by side, by day one. Both humans and chatbots communicate on a text-based, full duplex channel that we commonly define as Instant messaging or simply the Chat. Choosing the right technology for our instant messaging engine was therefore a crucial step.
Initially we explored a lot of open-source instant messaging engines. In the end – after discarding all of them (see below for the reasons) – we decided to build our own, open-source messaging engine. We opted for the MQTT protocol for its flexibility and leveraged the robust message brokering and MQTT support offered by RabbitMQ to bring our solution to life. In this short article I’ll tell you why we opted for the MQTT protocol and some details about the Tiledesk Instant messaging internal architecture design.
MQTT (https://mqtt.org/), which stands for Message Queueing Telemetry Transport, is a simple and lightweight messaging protocol. This protocol is ideal for the Internet of Things (IoT) as it is designed to support persistent connections with low bandwidth, meaning connections where the maximum data transfer amount is very limited, between devices with similarly limited resources.
MQTT operates following a publish-subscribe paradigm, which allows devices to communicate asynchronously through a broker that manages messages between the devices.The use of the MQTT protocol, originally designed to facilitate communications in the IoT scope, has been extended to domains often unexpected due to the fact that the principles and methods used for IoT messaging are well-suited to apparently very different domains. One surprising aspect has been its adoption, for example, in instant messaging. Large companies such as Facebook (Meta) have adopted it as the protocol for their messaging applications.
In general, a chat client – an application capable of sending and receiving real-time messages to and from other similar applications – has characteristics analogous to those of an IoT device.
Typical messaging applications (e.g. Facebook Messenger, WhatsApp or Telegram) share the following requirements:
- Ability to manage a list of contacts.
- Enable sending and receiving “direct” text messages, i.e., from one contact to another, in real-time.
- Allow “group” conversations among contacts, where a contact sends a message to a group of participants simultaneously.
- Monitor the “presence” status of contacts, i.e. determine online or offline status in real-time.
- Support the transmission of binary files, such as images, videos, documents, geographic locations, etc.
- Support for the exchange of metadata with flexible and evolving schemas (i.e. Carousels and Galleries).
- Archive the history of exchanged messages.
In this context, the MQTT protocol proves particularly effective in implementing messaging functionalities, inherently covering the points 2, 3, 4, 5, and 6 listed above. This effectiveness has motivated the choice of Tiledesk to adopt MQTT for its open source instant messaging engine, called Chat21.
On the contrary, although considered, other protocols such as XMPP were not taken into consideration due to their complex nature. XMPP, which is based on the XML protocol, has some significant limitations, such as:
- The verbosity of the XML language, which tends to increase the volume of transferred data without adding relevant information, thereby consuming precious bandwidth resources.
- Computationally heavy parsing, which can be a limiting factor on devices with limited resources.
- Difficulty in evolving the XMPP standard, which hinders easy adaptation to the specific requirements of Tiledesk’s rapidly evolving requirements.
These factors have led to opt out for MQTT over other protocols, as it is considered more suitable for meeting the needs of a modern messaging system.
The adoption of MQTT as the protocol underlying the Tiledesk messaging infrastructure also brings advantages such as reducing communication overhead and facilitating the immediate integration of new clients into the established communication ecosystem.
Considering that most of the Tiledesk clients applications are designed to work in the Browser (i.e. the Web Widget or the Agents’ chat application), we used MQTT.js library for the implementation of the MQTT protocol. We found MQTT.js library actively maintained, versatile and compatible with various runtime environments, both server-side (with NodeJS) and client-side with web applications running directly in the browser.
The MQTT protocol offered the following key advantages:
- Communication Efficiency: MQTT is designed to efficiently support communication between low-power devices with minimal computational capacity and limited bandwidth. This aspect is crucial for ensuring smooth and reliable messaging in contexts characterized by limited hardware resources (i.e. smartphones).
- Payload Flexibility: Another significant aspect is the ability to construct a freely structured message payload. MQTT does not impose a predefined data schema, allowing for the free design of data models based on specific application needs. This eliminates the need to conform to rigid standards (as XMPP) and facilitates the adaptation of the protocol to various use cases.
- Wide Platform Availability: There is a wide range of platforms, both open source (e.g., RabbitMQ, our choice) and commercial (such as HiveMQ), that offer native support for managing MQTT connections.
Integrated Presence Management: MQTT incorporates native mechanisms for managing the presence state of devices, a fundamental function for both IoT devices and communication management between humans. The ability to monitor the availability of interlocutors in real time is essential for building an Instant messaging solution.
In conclusion, MQTT stands out for its ability to offer efficient, stable communication well supported by a wide variety of platforms, essential for managing heterogeneous IoT devices, as well as for its ability to ensure high performance and efficient resource management. These aspects made it particularly suitable for meeting the needs of our dynamic messaging context where computational lightness, data flexibility, and reliable connections management are essential requirements. Everything without reinventing the wheel.
RabbitMQ, the “core”
RabbitMQ (https://www.rabbitmq.com/) has been also chosen for its very powerful native support to the MQTT protocol and to ensure all the scalable and resilient design we needed from a Message Broker.
The Message Broker is a software intermediary whose task is to mediate communication between different systems, applications, or devices. It receives messages from a sender, or publisher, and directs them to their recipients, or consumers. The Message Broker plays a key role in message-oriented architectures and distributed systems, where various components need to communicate with each other reliably and scalably.
The main advantage of using RabbitMQ as a message broker lies in its support for MQTT, which became “native” starting from version 3.12 of RabbitMQ. This factor marked a significant advancement in performance, allowing the simultaneous management of millions of devices and the sending of millions of messages. And this was the main reason to rely on RabbitMQ for the new messaging engine as well as his support for AMQP 0.9.1 protocol because there was a need for a versatile and robust messaging system capable of supporting a wide variety of communication patterns and ensuring great reliability, including messages consistency, which is mandatory in the complex instant messaging scenario. In fact, AMQP 0.9.1 offers a feature set that reflects the requirements identified during the design phase, such as flexible message routing, delivery confirmation, and support for transactions.
As mentioned earlier, the open-source nature of RabbitMQ can only be seen as a significant advantage for our open-source platform, offering the possibility of customization and extension of the broker to meet the specific needs of the project, avoiding limitations and additional costs for us and our Community. Other advantages include the presence of a plugin ecosystem provided by the developer community that has evolved around the protocol.
Chat21, the ‘postman’
Below there is a simple diagram illustrating the main components of the Tiledesk Instant messaging architecture.
The chat clients, whether they are web/iOS/Android, use the open-source MQTT.js library (https://github.com/mqttjs) to establish a direct connection with the RabbitMQ message broker.
The Chat21 Server component (https://github.com/chat21/chat21-server), which interfaces with RabbitMQ using the AMQP protocol, acts as a simple “Observer” on message streams via the AMQP protocol.
Client applications (i.e. the Web Widget in the picture above) leverage the MQTT protocol to connect to RabbitMQ, allowing end-users to transmit messages through specific paths, access to which is regulated by custom JWT tokens granted by RabbitMQ. The RabbitMQ JWT tokens contain specific information about the allowed topics (paths) a user can write to. We used this possibility to allow users to only write to a topic that contains the /apps/tilechat/users/USER-ID. Users can never write directly to the recipient topic. This mechanism ensures that each client can write messages exclusively to their designated paths, as illustrated in the following example:
/apps/tilechat/users/USER-ID/RECIPIENT-USER-ID/messages/outgoing
When a client connected via MQTT sends a message, it is transmitted to RabbitMQ as a JSON payload, addressed to the ‘/outgoing’ path. The Chat21 Bbserver component subscribed to all paths (including this one) proceeds to receive notification of the message and forwards it to the designated recipient’s path using an AMQP publish operation, following the schema:
/apps/tilechat/users/RECIPIENT-USER-ID/SENDER-USER-ID/messages/clientadded
The recipient’s receipt of the message occurs through MQTT publish notifications, which, once decoded, notifies the arrival of a new message, as indicated by the specific end of the path, for example, ‘/clientadded’.
Through the implementation of this system, Chat21 realizes a structure functionally equivalent to that of an “inbox,” where messages are not transmitted directly between clients but mediated by the observer (Chat21 Server), thus allowing for a more rigorous protocol on privacy, security, data persistence, and the application of specific message policies, including the ability to block users.
The security of the system is further strengthened by adopting a granular security model based on RabbitMQ JWT tokens, which limits users’ operations to only their assigned paths, thereby preventing unauthorized access or modification to others’ mailboxes.
In conclusion, the operational model of the messaging system under consideration is inspired by the principles of SMTP/POP3 email protocols, where messages are sent to a designated mail server mailbox (the ‘/outgoing’ path), to be subsequently redirected by the observer to the recipient’s mailbox, where they will be available as soon as the recipient establishes a connection with RabbitMQ.
Compared to the raw messaging engine based on MQTT which offers functions exclusively related to messaging, Tiledesk adds some features oriented towards “support” chats. These represent an evolution of traditional group chats and are characterized by the ability to be instantiated “on-the-fly” and to host one or more chatbots along with humans within the same group to optimize request management.
Additionally, the platform supports the creation of anonymous users, ensuring simplified and immediate access to the support service, as well as the creation of users with advanced authentication mechanisms.
Finally, Tiledesk integrates a powerful automation engine capable of interpreting and implementing complex logic through the use of no-code, generative-AI powered tools. This allows for flexible and accessible design of automated workflows, leading to increased efficiency of the support service, reduced response times, and personalized interactions based on the specific needs of users.
Conclusions
About numbers. Actually we exchange an average of 200 messages/second, with peaks of 500 messages/second only leveragin on our own instant messaging engine. Choosing market-proven protocols and platforms like MQTT and RabbitMQ was the right choice. Thanks to flexible standards (MQTT) we can evolve the messaging engine really fast, following all the upcoming Tiledesk needs. And we have a lot of upcoming needs. Due to AI penetration into Tiledesk, the messaging engine was the first to be involved by the AI-wave. As an example we are adding the ability to stream text messages, something that is mandatory for generative AI when you have the goal to reduce the long delays of LLM response generation returning to the users the message text (or a portion of it) as soon as it is generated. With XMPP this had been an impossible advancement, while MQTT/RabbitMQ allow for a lot of flexibility. Big messaging players moved already to the MQTT choice for messaging (i.e. Facebook Messanger) and more of them probabily will do. We released our Chat21 engine open-source to provide everyone the opportunity to work on it or use it as a prototype for their own messaging engine. It’s MIT licence, for maximum flexibility.
Enjoy Tiledesk!
For more info, or if you want to know how Tiledesk will solve your Company AI-needs don’t esitate to write us: info@tiledesk.com
