MQTT Brokers

The message broker is an intermediary program between the sender and the receiver that ensures that messages from a sender are routed to the correct receiver with guaranteed delivery. In addition to its core function of message routing, the message broker may also perform additional tasks, such as message validation (based on rules probably defined in the message broker) and message transformation (if the message format needs to be changed from what is sent by the sending program to what can be processed by the receiving program).

There are quite a few different messaging protocols where the most common open protocols are AMQP (Advanced Message Queuing Protocol) and MQTT (MQ Telemetry Transport). AMQP provides a wide range of features related to messaging, including reliable queuing, topic-based publish-and-subscribe messaging (we will learn more about this in the next lesson), flexible routing, transactions, and security. This protocol was designed for reliability and is suitable for enterprise applications where these features are essential for building a large-scale and reliable messaging infrastructure. However, this protocol requires a higher network bandwidth since the amount of data added to process the message is large.

On the other hand, MQTT is a lightweight protocol, which is specifically designed for devices that need to communicate over low-bandwidth, high-latency, or unreliable networks. The design principles are to minimize network bandwidth and device resource requirements, which also ensure reliability and some degree of assurance of delivery. These principles also turn out to make the protocol ideal of the emerging “machine-to-machine” (M2M) or “Internet of Things” world of connected devices and for mobile applications where bandwidth and battery power are at a premium.

Websocket

WebSocket is a computer communications protocol that makes it possible to open an interactive communication session between a web browser or a mobile app (a client) and a server. With this protocol, a server can alert the client regarding any change to data without the client needing to make a request. In a traditional request/response protocol, the client has to send a request to the server to get some data. If there is any change in the data on the server, the client will not be aware of the change until it sends the next request. In use cases where data changes infrequently or the user does not need to be updated data changes in real-time, the request-response approach works fine.

With this approach, if all users are required to know of any changes on the server data at the same time, then the client has to run in a loop sending a request as frequently as the user needs to be updated (known as polling). Websocket is a good alternative solution for this. It allows the client to establish a connection with a server and then keep that connection open. Once the connection is established, every time there is a change in the server data, it sends the data to the client. If there is no data, the client can stay idle. This approach is well-suited for IoT applications that need to work in real-time (as soon as a sensor reads some data, the user needs to be made aware immediately).