Skip to content

Explain why MQTT is a good fit for RSMP #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Explain why MQTT is a good fit for RSMP #16

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8c66de9
Explain why MQTT is a good fit for RSMP
otterdahl Sep 30, 2024
b74ce12
Update according to feedback
otterdahl Jan 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions mqtt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,76 @@ RSMP 4 is expected to be build on top of [MQTT](https://mqtt.org/), a protocol p

MQTT is based on a publish-subscribe model with a broker in the middle and topics as a flexible way to route and filter message.

## Why MQTT?

RSMP were designed and developed about 15 years ago. Over the years RSMP has
been regularly updated to include more features since more desired use cases has
been identified.

As the RSMP specification has evolved the limitations of some of its original
designed choices has gotten more apparent. This includes several aspects of the
protocol.

### Performance

By default, RSMP sends all data as human readable JSON. Although it's great for
troubleshooting, it also means that each RSMP packet is quite large and uses a
relativity high amount of network traffic.

Each packet transmitted needs to be acknowledged, not just on the underlying TCP
layer, but also on the RSMP layer using "MessageAck". This leads to a high
amount of network roundtrips increasing network traffic and latency.

RSMP has built in support for buffering to compensate for unreliable networks.
Up to 10000 messages must be buffered in the equipment and sent upon connection
reestablishment. But since RSMP doesn't prioritize any messages and all messages
needs to be sent using the FIFO-principle it means that all buffered messages
needs to delivered before the most recent messages can be transmitted. This
means it may take a long time between connection establishment and receiving the
current state of the equipment - especially if the connection is slow.

### Management

RSMP doesn't have any concept of auto discovery of the connected equipment and
requires a relative large amount of configuration in order to work correctly.

In order to support communicating with multiple supervisors, each controller
needs to independently establish connection to each supervisor, including
keeping track of all associated connection related parameters. The controllers
also need to implement access control to prevent any management system to send
arbitrary commands.

To mitigate performance related issues regarding buffering, the controller needs
to be configured not to buffer unneeded message types. This configuration needs
to be done for each controller.

Updating RSMP to adress these issues is possible, but not backwards compatible.
A better use of our efforts is to rely on existing standards where these issues
already are addressed.

### Design of MQTT

MQTT is well known and established in the industry with many well proven
implementations in use.

MQTT introduces a concept of QoS which ensures a higher level of robustness of
message delivery, partially replacing the need of buffering data which is part
of the current specification. Any further need to transfer historical data can
be implemented separately where needed.

Instead of using a traditional client-service architecture MQTT uses broker in
the middle. The use of a broker solves several issues that currently exists in
RSMP. It solves performance issues since publishing and subscriptions can be
handled independently of each other. It also handles management issues since the
equipment doesn't need to keep track of communicating with several management
systems. Access control can be managed by the broker.

Copy link

@RazeAntoine RazeAntoine Oct 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about adding this :

"By leveraging load balancing, MQTT could distribute the communication load across multiple brokers, potentially enhancing system performance under heavy traffic. The ability to broadcast messages to groups of devices using topic hierarchies might further optimize message delivery. These features could contribute to better management of system load and improve overall resilience, ensuring uninterrupted communication even under failure or high-demand scenarios.

graph LR;
  MQTT1<--->MQTT2;
  MQTT1<--->MQTT3;
  MQTT2<--->MQTT3;
Loading

"

source : https://docs.hivemq.com/hivemq/latest/user-guide/load-balancer.html#:~:text=In%20a%20HiveMQ%20deployment%2C%20the,messages%20to%20all%20available%20brokers.

Copy link
Member

@emiltin emiltin Oct 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea to include a section on scalability.

Copy link
Author

@otterdahl otterdahl Jan 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the feedback. I've updated the draft.

MQTT also has mature and proven standard software libraries and simulators which
is readily available.

Adopting MQTT in RSMP means that we can focus on the content of the messages
instead of the transport mechanisms.

## MQTT Broker
In MQTT, clients all connect to the broker, which routes messages according to which topics are used when subscribing and publishing:

Expand Down