Re: [mqtt-comment] Lifetime of topic alias map

[Takatoshi Kondo <redboltz@gmail.com>]

Hi Roger,

# Added missing mqtt-comment@lists.oasis-open.org to CC

Thank you for the comment.
It is very helpful understanding the spec.

I didn't notice that the PUBLISH message for resending that contains
empty TopicName and TopicAlias property is a part of Topic Alias
mappings.
Now I understand it. So my problem is completely solved!
Thanks again.

The following part is a note from the library developper's view.

I'm developping MQTT v5 client library https://github.com/redboltz/mqtt_cpp

It has publish function. The library user can use a combination of
empty Topic Name and TopicAlias property as long as the mapping exists
in the current connection. It is a flexible and natural interface.
And the library automatically re-send inflight PUBLISH and PUBREL
packet. Inflight means send PUBLISH but not received PUBACK or PUBREC,
and send PUBREL but not received PUBCOMP.

In order to satifsy the spec, the library shouldn't re-send the same
PUBLISH packet as the first sent when reconnected.

The library needs to prepare the PUBLISH packet for resending.
It is one of possible implementation that the library copies the
original packet to the packet for resending. Then modify the packet
for resending as follows:
1. Get the Topic Name from the Topic Alias property
2. Recover Topic Name
3. Remove Topic Alias property.
Now, the packet for resending satisfied the spec because Topic Alias
mappings information has completely removed from the packet for
resending.
In order to the step 1, the library needs to manage Topic Name - Topic
Alias mapping for sending.

---
Thanks,
Takatoshi

On Wed, Jan 20, 2021 at 7:31 PM Roger Light <roger@atchoo.org> wrote:
>
> Hi Takatoshi,
>
> The key point is this section from the specification, which you did highlight:
>
> Topic Alias mappings exist only within a Network Connection and last
> only for the lifetime of that Network Connection. A receiver MUST NOT
> carry forward any Topic Alias mappings from one Network Connection to
> another [MQTT-3.3.2-7].
>
> You ask about the following scenario:
>
> 5. Disconnect between the client and the broker. Broker clears the map here.
> 6. Client connects to the broker with CleanStart: false
> SessionExpiryInterval=0xfffffffff(infinity)
> 7. Client publishes empty topic  with TopicAlias: 1, QoS: 1,
> PacketId:2 (PUBACK PacketId: 2 is not received so resend step 3
> message)
>
> In this scenario, the client does not conform to the specification
> because it has kept its topic alias mapping beyond the life of the
> network connection. As soon as it disconnected, the mapping should
> have been deleted.
>
> If a client does send a PUBLISH message with an empty topic and a
> topic alias set, but there is no mapping for this topic alias, as
> above, then this part of section 3.3.4 applies:
>
> 3)    If the receiver does not already have a mapping for this Topic Alias
>  a)    If the packet has a zero length Topic Name field it is a
> Protocol Error and the receiver uses DISCONNECT with Reason Code of
> 0x82 (Protocol Error) as described in section 4.13.
>
> Regards,
>
> Roger
>
> On Fri, 14 Aug 2020 at 05:54, Takatoshi Kondo <redboltz@gmail.com> wrote:
> >
> > Hi,
> >
> > I have a question about the lifetime of TopicAlias map.
> >
> > According to https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Topic_Alias
> >
> > > Topic Alias mappings exist only within a Network Connection and last only for the lifetime of that Network Connection.
> >
> > It seems that the lifetime of the map is over when the network
> > connection is closed.
> >
> > Consider the following scenario.
> >
> > 1. Client connects to the broker with CleanStart: false
> > SessionExpiryInterval=0xfffffffff(infinity)
> > 2. Client publishes topic1 with TopicAlias: 1, QoS: 1, PacketId: 1
> >    Broker inserts topic1 - ToppicAlias 1 entry to the map.
> > 3. Client publishes empty topic  with TopicAlias: 1, QoS: 1, PacketId: 2
> >    Broker finds topic1 from the map using TopicAlias 1 as the key.
> > 4. Client receives PUBACK PacketId: 1.
> > 5. Disconnect between the client and the broker. Broker clears the map here.
> > 6. Client connects to the broker with CleanStart: false
> > SessionExpiryInterval=0xfffffffff(infinity)
> > 7. Client publishes empty topic  with TopicAlias: 1, QoS: 1, PacketId:
> > 2 (PUBACK PacketId: 2 is not received so resend step 3 message)
> > 8. Broker can't find the topic corresponding to the TopicAlias: 1 in
> > the map because the map has been cleared at the step 5.
> >    What should happen here? Should the broker disconnect the client
> > due to no matching TopicAlias with empty TopicName ?
> >
> > If the client continues to re-connect with the same parameter, the
> > publish packet at the step 3 is never processed by the broker.
> > The client needs to set CleanStart: true to erase re-send publish
> > message. But it avoids message deliverty guarantee.
> >
> > I think that if the lifetime of the map is the same as session
> > lifetime, it is easy to use.
> > At the step 5, broker dossn't clear the map. The lifetime of the map
> > is extended until the session lifetime is over.
> >
> > However, session is defined as follows:
> >
> > https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc473619931
> >
> > > A stateful interaction between a Client and a Server. Some Sessions last only as long as the Network Connection, others can span multiple consecutive Network Connections between a Client and a Server.
> >
> > It seems ttat Network Connection and session are different concept.
> >
> > I think that TopicAlias mapping should have the same lifetime as the
> > session lifetime.
> >
> > Any ideas?
> >
> > ----
> > Thanks,
> > Takatoshi
> >
> > --
> > This publicly archived list offers a means to provide input to the
> > OASIS Message Queuing Telemetry Transport (MQTT) TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe: mqtt-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: mqtt-comment-unsubscribe@lists.oasis-open.org
> > List help: mqtt-comment-help@lists.oasis-open.org
> > List archive: http://lists.oasis-open.org/archives/mqtt-comment/
> > Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > Committee: http://www.oasis-open.org/committees/mqtt
> > Join OASIS: http://www.oasis-open.org/join/
> >