MQTTv5.0: New Features Overview. Part 2

Hello!



The material below is a continuation of the article about the functionality added in the new version of MQTTv5.0. If you have already studied it, then it will not be difficult for you to notice that most of the new functions are based on the concept of properties that can be added to the package. In this article, we will analyze them in detail.



Approx. - The article is aimed at those who have an interest or need to dive deeply into the intricacies of MQTT. There will be no pictures and lyrical digressions here, only hardcore !!!



Below is a table of all properties ( see section 2.2.2.2 in the specification ).







Now let's take a closer look at them.

Payload Format Indicator - payload format indicator

• 0 - data is a set of undefined bytes, which is equivalent to not sending a payload format indicator,
  
  
• 1 - the data is UTF-8 encoded character data.
  
  

Message Expiry Interval - message expiration interval

A number representing the message expiration interval (in seconds).



If the message expiration interval has passed and the server was unable to deliver the message to the correct subscriber, it must delete the message for that subscriber.

Content Type - content type

The meaning of the content type is determined by the sending and receiving client.

Response Topic - a topic for a response

A UTF-8 string that is used as the topic for the reply message.



The recipient of the message with the specified topic for the reply sends his reply, using this topic as the topic of his publication.



The request / response interaction in this case occurs as follows ( see clause 4.10.1 in the specification ):

1. The client (sender) publishes a request message with some topic, which specifies the topic for the response.
   
   
2. () , , . . , .
   
   
3. , , .
   
   
4. . - . , .
   
   

Correlation Data —

The correlation data is used by the sender of the request message to determine which request the response message belongs to when it is received. If there is no correlation data, then the requester does not require any correlation data.



If the request message contains correlation data, the receiver must also include the correlation data as a property in the PUBLISH packet of the response message.



The correlation data value is meaningful only to the sender of the request message and the receiver of the response message.

Subscription Identifier - subscription identifier

A number representing the subscription ID.



If the publication is the result of a match with more than one subscription, multiple subscription IDs will be specified, in which case their order does not matter.



A customer can also make multiple subscriptions that match a given publication and use the same identifier for multiple of them. In this case, the PUBLISH package will contain several identical subscription IDs.



The Subscription ID is associated with any subscription created or modified as a result of the SUBSCRIBE package. If there is a subscription ID, it is saved with the subscription. If this property is not specified, then no subscription is saved with the subscription.



Subscription IDs are part of the session state on the server and are returned to the client receiving the corresponding PUBLISH packet. They are removed from the server session state when the server receives a UNSUBSCRIBE packet, when the server receives a SUBSCRIBE packet from the client for the same topic filter but with a different subscription ID or no subscription ID, or when the server sends a Session Present of 0 in the CONNACK packet.

Session Expiry Interval - session expiration interval

A number representing the interval to expire the session (in seconds).



If there is no session expiration interval, the value 0 is used. If it is set to 0 or not present, the session ends when the network connection is closed.



If the session expiration interval is 0xFFFFFFFF (UINT_MAX), the session does not expire.



The client and server must keep the session state after the network connection is closed if the session expiration interval is greater than 0.



The client can connect to the server over a network that provides an intermittent connection. This client can use a short session expiration interval so that it can reconnect when the network becomes available again and continue to reliably deliver messages. If the client does not have time to restore the connection, the messages will be lost.



Setting Clean Start to 1 and expiration interval 0 is equivalent to setting CleanSession to 1 in the MQTT specification version 3.1.1. Setting Clean Start to 0 and no session expiration interval is equivalent to setting CleanSession to 0 in MQTT specification version 3.1.1.

Assigned Client Identifier - assigned client identifier

A string that is the server-assigned client ID. Used if a zero length client identifier was used in the CONNECT packet.

Server Keep Alive - Keep Alive server

A number that defines the Keep Alive time assigned by the server. If the server returns Server Keep Alive in a CONNACK packet, the client MUST use that value instead of the value it sent it as Keep Alive. If the server does not send Server Keep Alive, it MUST use the Keep Alive value set by the client in the CONNECT packet.



The primary use of Server Keep Alive for a server is to inform the client that it will disconnect the client in case of inactivity before the client's specified Keep Alive times out.

Authentication Method - authentication method

A string containing the name of the authentication method used for extended authentication.



If there is no authentication method, then extended authentication is not performed.



An authentication method is an agreement between a client and a server about the meaning of the data sent in the authentication data and any other fields in CONNECT, and the exchanges and processing required by the client and server to complete the authentication. The authentication method is usually a SASL mechanism.

Authentication Data - authentication data

Binary data containing authentication data. Sent only if an authentication method is specified. The content of this data is determined by the authentication method.

Request Problem Information - information about the request problem

The client uses this value to indicate whether a reason string or custom properties is dispatched on failure.

• 0 - the server can return a reason string or custom properties in a CONNACK or DISCONNECT package, but should not send a reason string or custom properties in any package other than PUBLISH, CONNACK, or DISCONNECT,
  
  
• 1 - The server can return a reason string or custom properties for any package where allowed.
  
  

Will Delay Interval - Will Message delay interval

A number representing the interval of the Will Message delay (in seconds). If there is no delay interval, the default is 0 and there is no delay before the Will Message is published.



The server delays posting the message until the delay interval expires or the session ends, whichever comes first. If a new network connection to this session is established before the delay interval expires, the server shall not send a Will Message.



One way to use this is to prevent the publication of a Will Message if there is a temporary disconnection from the network and the client is able to reconnect and continue the session before the message is published.

Request Response Information - request information for a response

A byte with the value 0 or 1. The client uses this value to request the server for the CONNACK response information.

• 0 - the server should not return response information,
  
  
• 1 - The server can return response information in a CONNACK packet, but this is not required even if the client requested this information.
  
  

Response Information - information for a response

A UTF-8 string that is used as the base for creating the Response Topic. The way the client creates a Response Topic from the response information is not defined by this specification.



Typically this is used to transmit a globally unique subset of topics that is reserved for this client, at least for the lifetime of its session. Using this mechanism allows this configuration to be performed once on the server rather than on each client.

Server Reference - link to the server

A string that can be used by the client to identify another server in use. The value of this string is a space-separated list of links. The format of the links is not regulated.



The server can request that the client use a different server by sending a CONNACK or DISCONNECT with a reason code “Use another server” or “Server moved”. When sending one of these codes, the server can also include a server reference property to indicate the location of the server or servers that the client should use.

• Use a different server - The client must temporarily switch to use a different server.
  
  
• Server moved - The client must always connect to a different server.
  
  

It is recommended that each link consist of a name followed by a colon and port number. If the name contains a colon, the name string can be enclosed in square brackets. A name enclosed in square brackets cannot contain the right square bracket character ("]"). This is used to represent an IPv6 address that uses a colon as a separator.



The name in a server link is usually the hostname, DNS name, SRV name, or IP address. The value after the colon is usually the decimal port number. This is not required if the port information is taken from the name (for example, for SRV) or is the default.



If multiple links are given, the client is expected to select one of them.

Reason String - the reason string

A string describing the reason associated with this response. The server uses this value to provide additional information to the client.



Correct use of the reason string in the client will include using this information in an exception thrown by the client code, or logging the reason string.

Receive Maximum - the maximum value of the number of QOS packets> 0

A number that sets the send quota, which is used to limit the number of PUBLISH QOS> 0 packets that can be sent without receiving PUBACK (for QoS 1) or PUBCOMP (for QoS 2). That is, this value is used to limit the number of QoS 1 and QoS 2 publications sent simultaneously. The client / server should not send messages with QoS 1 and QoS 2 if there are Receive Maximum messages sent that have not yet received replies. When the Receive Maximum is reached, sending packets with QoS 0 can also be paused, but not required. At the same time, there is no need to delay the sending of packets other than PUBLISH.



If both the client and the server have set the Receive Maximum to 1, they make sure there are no more than one message "in flight" at the same time.



The specified value applies only to the current network connection and is reinitialized on reconnection.



If not specified, it defaults to 65,535.

Topic Alias ​​Maximum - the maximum value of the topic alias

A number that represents the maximum value for a topic alias.



This value indicates the largest value that is accepted as the topic alias. It is used to limit the number of topic aliases that need to be stored in this connection.

Topic Alias ​​- topic alias

To reduce the size of the PUBLISH packet, the sender can use a topic alias. This is an integer value that is used to identify the topic instead of using the topic name. This technique reduces the size of the PUBLISH packet and is useful when topic names are long and the same name is often reused on a network connection.



On the recipient's side, when receiving an alias for a topic, the necessary correspondence is established between the topic and its alias.



If the PUBLISH package contains a topic alias, the receiver processes it as follows ( see section 3.3.4 in the specification ):

1. ,
   
   a) , , ,
   
   b) , , , .
   
   
2. ,
   
   a) ,
   
   b) , .
   
   

Maximum QoS — QoS

Can be 0 or 1. If there is no maximum QoS, the client uses the maximum QoS of 2.



If the server does not support PUBLISH QoS 1 or QoS 2 packets, it MUST send the maximum QoS in a CONNACK packet indicating the highest QoS it supports.



If the Client receives the maximum QoS from the Server, it should not send PUBLISH packets with a QoS level exceeding the specified maximum.

Retain Available - saving is available

• 0 - saved messages are not supported,
  
  
• 1 - saved messages are supported.
  
  

A client receiving a Retain Available value of 0 from the server MUST NOT send a PUBLISH packet with the RETAIN flag set to 1.

User Property - user property

It is a string pair “name” - “value”. This property, unlike others, can appear multiple times. The same name can be used for multiple properties.



This property can be used to provide additional diagnostic or other information.



The meaning of these properties is not specified in the specification, their meaning and interpretation are known only to the sending and receiving clients.

Maximum Packet Size - maximum packet size

A number that specifies the maximum packet size that the client / server is willing to accept. The packet size is the total number of bytes in the MQTT packet. This property is used to indicate that packets exceeding this limit will not be processed.



If there is no maximum packet size, no packet size limit is imposed.



It is the application's responsibility to select an appropriate maximum packet size value if it chooses to limit the packet size.

Wildcard Subscription Available - Wildcard subscription available

• 0 - wildcard subscriptions are not supported,
  
  
• 1 - such subscriptions are supported.
  
  

If the property is missing, then wildcard subscriptions are supported.



If the server supports wildcard subscriptions, it can still reject a specific subscription request that contains a wildcard subscription.

Subscription Identifier Available - the subscription identifier is available

• 0 - subscription IDs are not supported,
  
  
• 1 - Subscription IDs are supported.
  
  

If the property is missing, then subscription IDs are supported.

Shared Subscription Available - Shared subscription available

• 0 - general subscriptions are not supported,
  
  
• 1 - general subscriptions are supported.
  
  

If the property is missing, then general subscriptions are supported.

Conclusion

Let me remind you that the article was born while working on embedding the emerging functionality described above into the service of the IoT platform. It also seemed to me that it is quite convenient to display the display of properties received from the client in the object interface ( you can read more about objects here >>> ). You can hide uninteresting properties, and you can add additional custom properties to display. In general, it looks like this. That, perhaps, is all. To test the functionality, I found this project redboltz / mqtt_cpp quite convenient and clear . I would be very glad if in the comments you share other open-source projects of MQTT clients (both with a GUI and without it) that support version 5.0.