Skip to content
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.

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

MQTT Port: Support for QoS 1/2 #71

Open
linuxbasic opened this issue Nov 30, 2020 · 1 comment
Open

MQTT Port: Support for QoS 1/2 #71

linuxbasic opened this issue Nov 30, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@linuxbasic
Copy link
Contributor

The MQTT Port currently only supports QoS 0 (At Most Once Delivery Guarantee). The reason is that the used MQTT library doesn't allow the delay of the PUBACK message until the message is processed (see eclipse/paho.mqtt.c#522).

We tried to patch the Cand rust library (see eclipse/paho.mqtt.c@master...ce-rust:feat/ack-after-processing and eclipse/paho.mqtt.rust@master...ce-rust:feat/ack-after-processing-0.8.0).
This patch allowed us to block in the message callback till the message was successfully delivered over another port.

But then we run into another problem: The C library uses the same threads and mutex for all the connections. In the case there are multiple MQTT Ports, the blocking of the message handler results in the blocking of the other connections => Dead Lock.

We then tried to fork the process before opening the connections. This way the different ports would not share the same threads and mutex. We tried to implement that in the port crate (see https://github.com/ce-rust/cerk/tree/feat/mqtt-port-subprocess) but unfortunately, forking the process in that stage of the router lifecycle results in unexpected behavior (see https://thorstenball.com/blog/2014/10/13/why-threads-cant-fork/).

Possible solutions:

  1. find MQTT library that supports the delay of PUBACK
  2. write a MQTT library that supports the delay of PUBACK
  3. implement a Scheduler component for the router that is not based on threads but on processes. (requires major changes in cerk, e.g. BrokerEvent must be serializable.
@Lazzaretti
Copy link
Member

Current workaround: use the cerk_port_mqtt_mosquitto port

@Lazzaretti Lazzaretti added the enhancement New feature or request label Jan 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants