MQTT 5.0 connection properties

MQTT connection

We know that in the MQTT protocol, there are two roles of client and broker, but clients cannot directly connect to each other, they must connect to the broker, and the broker completes the message routing. The connection can only be initiated by the client. First, the client needs to establish a TCP connection with the Broker, and then sends a CONNECT message. The Broker responds with a CONNACK message to indicate whether to accept the connection.

The CONNECT packet contains fields such as Client Identifier, User Name, and Password, which provide the necessary information for connection:

Protocol Name, Protocol level

The protocol name is fixed to MQTT, which can be used by the firewall to identify MQTT traffic; the protocol version identifies the currently used MQTT protocol version, and the broker can determine whether it can provide services for this client based on this field.

Keep Alive

Indicates the maximum message sending interval of the client. If the client fails to maintain communication within the keep-alive time, the Broker will disconnect the current connection. In MQTT 5.0, the CONNACK message returned by the Broker may contain the Server Keep Alive field. Its main function is to notify the client that the Broker will disconnect the inactive ones faster than the client-specified keep-alive. The client, at this time, the client should take the value of Broker Keep Alive as the maximum packet sending interval after the connection is established.

Clean Start

Indicates whether the Broker needs to reuse the existing session for the current connection. For details, see Fresh Start Identification and Session Expiration Interval .

Client Identifier

It will be used by the Broker to uniquely identify the client and the current status of the client, such as the client's subscription list, message sending and receiving status, etc. When the client disconnects and reconnects, the Broker will complete the session recovery based on the Client ID.

User Name, Password

Optional field for Broker to authenticate and authorize.

Will Topic, Will Payload and other fields

Optional fields, used to specify the subject, QoS, Payload, etc. of the MQTT Will Message .

MQTT 5.0 connection properties

In addition to the above fields, MQTT 5.0 newly introduces the concept of attributes. Different types of packets have different attributes, which further enhances the scalability of the protocol.

capacity negotiation

The newly added attribute fields in CONNECT and CONNACK messages mainly enhance the negotiation capability between the client and the broker. For example, the maximum packet length that the Client and the Broker can accept can be negotiated through the Maximum Packet Size attribute. The Broker can inform the Client of the maximum quality of service that it can support through the Maximum QoS (Maximum QoS) attribute, so that the Client can decide to change The QoS of subsequent PUBLISH packets is also disconnected.

Similar to the Maximum Packet Size attribute, there are also the Session Expiry Interval, Receive Maximum and Topic Alias Maximum attributes, which also exist in CONNECT and CONNACK messages, so they can inform each other of their own processing capabilities during the connection process, so that the other party can provide services according to their expectations.

Optional server features

Considering that not all MQTT Brokers are fully implemented and may not provide complete MQTT 5.0 functions, MQTT 5.0 also supports optional server-side functions. The Retain Available attribute in the CONNACK message can be used to declare whether to support retained messages, the Wildcard Subscription Available attribute can be used to declare whether wildcard subscriptions are supported, the Subscription Identifier Available attribute can be used to declare whether to support subscription identifiers, and the Shared Subscription Available attribute can be used to declare whether to support Shared subscription. Clients should follow these declarations for subsequent operations.

Automatically assign Client ID

Through the Assigned Client Identifier attribute in the CONNACK message, MQTT 5.0 also provides a very convenient function, that is, it allows the Broker to uniformly assign the Client ID to the Client instead of the Client assigning it by itself. After all, the Client is assigned a globally unique Client in advance. ID is not an easy task in some scenarios. The use of this new feature is also very simple. As long as the Client provides a zero-byte Client ID when connecting, the Broker will carry the Assigned Client Identifier attribute in the response CONNACK message, and the value of this attribute is the automatically assigned Client ID. The Client can hold and use this Client ID until the session expires.