Payload format indicator and content type
The payload format indicator is set when the message is published (see the Payload Format Indicator property) as one of two options:

binary – the same as in v3.1,
UTF-8 string is new in v5.
The function is useful for the receiver to know if it needs to decode the message payload.

You can also specify a MIME-style content type when publishing messages (see the Content Type property).

Aliases for topics
Aliases are a mechanism for reducing the size of published packages by reducing the size of the topic.

The created topic alias can be used instead of the topic itself. If the topic homes/house1/upstairs/light1 has an alias of 1 (see the Topic Alias property), then this number can be used instead of the topic string when posting messages.

Before using topic aliases, the client must specify the maximum number of aliases (see the Topic Alias Maximum property) for the server. By default, if this is not set, topic aliases are not used by the client.

Response to a request
In web applications, the client (browser) makes a request and the server responds. At the same time, MQTT uses a publish and subscribe pattern where there is no direct relationship between the sending and receiving client.

Using a response topic (see the Response Topic property) in a publish message allows you to implement the request/response pattern common in web applications. This creates a virtual connection between the clients, so that one of the clients can function as a traditional server, although the packets still pass through the broker.

Subscription Features
Lack of local publications
In MQTTv3.1.1, if you have subscribed to a topic you post to, you will receive all the posts you post. By using the no local posting option, you can avoid the broker sending you messages that you posted yourself.

Saved messages control
Stored messages still work as they did in version 3.1.1, but subscription options have now been added to control what the client receives:

0 – Send saved messages when a client subscribes. Same as in MQTT 3.1.1,
1 – Send saved messages when the client subscribes if the subscription does not currently exist.
2 – Don’t send saved messages when a client subscribes.

Subscription ID
When subscribing, you can specify an identifier (see the Subscription Identifier property) corresponding to this subscription. When a message is received, the client then has the opportunity to determine which subscription or subscriptions resulted in the delivery of the message.

Shared subscriptions (see clause 4.8.2 in the specification)
The idea is to provide client load balancing. With normal subscriptions (not shared subscriptions), if, for example, 4 clients subscribe to the same topic and the client publishes a message with that topic, then the message is sent to all 4 subscribed clients.

With a general subscription, the message will be sent to only one of the subscribed clients.

A topic for such a subscription must begin with the $share keyword.

The topic filter format is as follows:

$share/{ShareName}/{filter}
$share – a function word, a character string that marks the topic filter as a shared subscription topic filter
{ShareName} — subscription name, character string, which should not include “/”, “+” or “#”
{filter} – the same as the topic in regular subscriptions
Example:

4 clients subscribe to $share/group1/my/topic, 3 clients subscribe to $share/group2/my/topic, and 3 clients subscribe to a regular subscription (2 my/topic and 1 wildcard subscription my/#).

Then, if the client posts a message for my/topic:

1 message sent to one of the clients subscribed to $share/group1/my/topic
1 message sent to one of the clients subscribed to $share/group2/my/topic
3 messages sent to regular subscribers
So a total of 5 messages are sent to clients.

General Features
Reason codes and strings for all ACK messages
In MQTTv3.1.1, there was very little indication from the server as to what went wrong at different stages:

establishing a connection
publishing a message
subscription to topics.
Now all acknowledgment packets (except PINGRESP) contain a reason code, 128 codes are available. It becomes much easier for the application to understand what happened and take appropriate action.

For example, publishing an ACK with reason code 16 means that there are no eligible subscribers. Therefore, in MQTTv5 it is possible to determine the extent to which a particular topic is used.

Keep in mind that reason codes are optional, a server/broker may still decide to simply disable clients as in MQTTv3.1.1, for security reasons, for example.

In addition to the reason code, a reason string can be associated with the response to provide a more readable message.

Server shutdown
In MQQTv3.1.1, only the client can send a disconnect message. If the server ran into problems, it would simply terminate the TCP/IP session. In MQTTv5, the server can send a disconnect message to the client along with a reason code (protocol error, unauthorized connection, etc.).

Examples of reason codes from the specification (see clause 3.14.2.1 in the specification):

Custom Properties
Added to all types of packages. They are defined by the user and are a set of key-value pairs (see the User Property). Useful for sending information outside of the payload, while in 3.1.1 any information was sent as part of the payload.

Custom properties, like all other properties, are sent by the broker from the sender to the receiver, unchanged and in the same order. An unlimited number of custom properties can be added.

Conclusion
For now, that’s all. In the next article, I will conduct a detailed analysis of all the properties added to the specification.

We will check the code performance on the Rightech IoT Cloud platform, which is why is specified as the address of the MQTT broker. Client identifiers are identifiers of objects created on the platform. For each check, I created a separate object on the platform, which is why in all the screenshots of the codes that will be presented below, only the line differs.

Note. – You can connect to the same object, then you can use the same code to flash all boards without changes, but make sure that in this case the boards do not connect to the same object at the same time, otherwise a collision will occur.

Leave a Reply

Your email address will not be published. Required fields are marked *