Skip to content

Automatic topic aliasing in rumqttc #972

@dnlmlr

Description

@dnlmlr

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions