Public access to internal topic alias mapping for proxying across connections

[codepitbull]

🚀 Feature Request

Going through the API I can't find a way to specify or receive an MQTT 5 topic alias.
This is weird since the connection parameters for controlling them are there.

🔈 Motivation

There should be a way to provide a topic alias for a PUBLISH-message.
There should be a way to read the topic alias returned from the broker in PUBACK.

[pglombardo]

Hi @codepitbull - if I'm not mistaken, topic alias are enabled and utilised by default without user intervention. It's a smart move for performance.

This should be documented to be made evident.

[codepitbull]

Yes, but in my request I talk specifically aout specifying those directly.
I am currently analysing cases in which I need to recreate topic-mappings on a different socket.
None of the information around mappings is available on the objects and I need to know and control the Topic Mappings created.

An example for how Paho is doing it:

The MqttProperties are available on every PUBLISH/PUBACK:

https://github.com/eclipse/paho.mqtt.java/blob/f4e0db802a4433645ef011e711646a09ec9fae89/org.eclipse.paho.mqttv5.client/src/main/java/org/eclipse/paho/mqttv5/common/packet/MqttProperties.java#L826

[SgtSilvio]

@codepitbull not exposing the topic aliases was an intentional decision. Topic aliases are only valid in the scope of a single connection. Before I go into too much details, I would like to understand what you are trying to achieve.

I am currently analysing cases in which I need to recreate topic-mappings on a different socket.

What do you mean by "recreating topic-mappings"? Proxy an MQTT connection? Then you have 2 connections that each should negotiate its own topic aliases. If the proxy alters or discards any messages, then reusing topic aliases would not be safe. If you want to proxy 1:1, then proxy the binary traffic.
Before we can label this as a feature request, we need to understand what you want to achieve.