rumqtt icon indicating copy to clipboard operation
rumqtt copied to clipboard

Automatic topic aliasing in rumqttc

Open dnlmlr opened this issue 6 months ago • 2 comments

I'm working with IOT software in a network traffic constrained environment, so I am currently trying to use thee MQTT v5 topic alias property to reduce the traffic. rumqttc supports this via manually setting the topic_alias field in the PublishProperties, as shown in the example.

While it is a bit tedious to keep track of the topic -> alias mapping externally since the sender (AsyncClient / Client) can be cloned and passed around anywhere, this is not that big of a deal. In general you can simply use a HashMap<String, u16> to keep track of the mapping. If a topic is not mapped yet, you send both topic and alias, otherwise you send an empty topic with the stored alias.

Where it becomes an issue is with disconnects and reconnects. The alias mapping is bound to the connection, so it is lost on every reconnect, even with durable session etc. This means you have to retransmit the topic + alias on all new packets after the reconnect. Effectively this involves clearing the HashMap on disconnect / connect events, causing the next messages to be sent with the mapping again. Unfortunately, since you can continue to publish messages while disconnected, there will be messages queued internally that only have the alias set and no topic. After a reconnect, the queued packets will be sent to the broker without a prior mapping being established, causing the broker to terminate the connection. Even when keeping track of the connected state and forcing a combination of topic & alias during disconnects, there can be messages sent during the timeframe where the connection is already dead, but not yet known to be.

Effectively this makes the use of alias only viable when you have clean_start enabled and discard any messages sent before connect events. (Event with clean_start, I had old messages without the topic going through but that might have been an issue on my end. If it is not on my end, one of the messages queues might not get cleared properly).

Long story short, I think it would be a nice feature to have automatic aliasing in the client. This would involve enabling this feature in the MqttOptions and then applying the topic_alias & deleting the topic automatically before actually sending the message to the broker. Since at that point the connection state is precisely known, it would be much easier to set the combination of topic_alias & topic correctly, depending on the connection state. The implementation could be done similar to how I described above with the HashMap<String, u16>.

Let me know if this sounds like something that would be suited for this crate and if there are any caveats to what I described.

dnlmlr avatar Jun 04 '25 19:06 dnlmlr

@dnlmlr Thank you for the detailed write-up. We will consider it for our next release.

Right now we are unable to give enough attention to opensource. We are tying to find ways to allocate more bandwidth

tekjar avatar Jun 16 '25 17:06 tekjar

@dnlmlr approach can be, user need to send publish packets with topic init (topic cant be empty), topic alias is managed by the lib , everytime it receives the publish it checks the topic in the HashMap and it it exists it sends publish with empty topic and with topic_alias , when it dont it sends the both , if current_topic_alias exceeds the max_topic_alias, then it resets the current_topic_alias, for every disconnect we can clear the maps and current_topic_alias CC @tekjar

giridher-art avatar Sep 07 '25 12:09 giridher-art