Introduction

At Coreflux, we continually enhance our broker to ensure it aligns with the latest MQTT 5.0 specifications, bringing new features and flexibility to IoT communications. MQTT 5.0 introduces extended control over message flow, better error reporting, and additional features like User Properties, Reason Codes, and Message Expiry Interval.

In this blog post, we’ll dive into the key MQTT 5.0 packet types and the new features that set MQTT 5.0 apart, particularly how they’re handled in Coreflux MQTT Broker with v5.0 MQTT specification. Since our broker is able to handle v.311 and v5.0 communications.

‍

‍

1. Message Expiry Interval: Why It Matters

Message Expiry Interval is a property in MQTT 5.0 that specifies how long a message should remain in the broker’s queue if it cannot be delivered immediately. Once the expiry period elapses, the broker discards the message instead of delivering an outdated payload. This feature is beneficial for:

• Time-Sensitive Data: Sensor readings that are only relevant for a short period.
• Reduced Redundancy: Prevents stale or irrelevant data from clogging the system.
• Clear Application Logic: Clients can set specific expiration times, ensuring messages align with operational requirements.

In Coreflux MQTT v5.0, you can set the Message Expiry Interval at the time of publishing using the message_expiry_interval property. The broker will automatically discard messages that exceed this interval without any extra client-side logic.

‍

‍

2. MQTT 5.0 Packet Overview

MQTT 5.0 retains the same packet structure from earlier versions (CONNECT, CONNACK, PUBLISH, PUBACK, etc.) but extends their functionality with Properties. Below is a quick overview:

1. CONNECT / CONNACK
2. PUBLISH / PUBACK (and related PUBREC, PUBREL, PUBCOMP)
3. SUBSCRIBE / SUBACK and UNSUBSCRIBE / UNSUBACK
4. PINGREQ / PINGRESP
5. DISCONNECT
6. AUTH

Let’s take a closer look at how each packet works, along with Mermaid diagrams to illustrate the sequence.

‍

‍

3. CONNECT & CONNACK

When a client first connects to the broker, it sends a CONNECT packet. The broker responds with a CONNACK to indicate whether the connection was successful.

Key properties in MQTT 5.0 for CONNECT include:

• Session Expiry Interval: How long the session state is preserved by the broker.
• Maximum Packet Size: To limit the size of packets the client is willing to accept.
• Authentication Method: For enhanced authentication flows.

CONNECT & CONNACK Sequence Diagram

‍

• Reason Code in CONNACK indicates success or error (e.g., 0x00 for success).
• Session Present tells the client if an old session was resumed.

‍

‍

4. PUBLISH & PUBACK (Basic Publish Flow)

After a successful connection, devices typically publish messages to topics. The broker then routes the messages to subscribers who’ve subscribed to those topics.

PUBLISH Packet

• Topic Name: The topic to which the message is published.
• Payload: The actual data (e.g., sensor reading).
• QoS Level: Determines the delivery guarantee (0, 1, or 2).
• Properties: Might include Message Expiry Interval, User Properties, etc.

PUBACK Packet

• Returned by the broker in response to a QoS 1 message to acknowledge receipt.
• Carries Reason Code and Properties if needed.

PUBLISH & PUBACK Sequence Diagram

If QoS 2 is used, there are additional steps: PUBREC, PUBREL, and PUBCOMP.‍

‍

5. SUBSCRIBE & UNSUBSCRIBE

Clients need to SUBSCRIBE to specific topics or topic filters in order to receive messages. Conversely, UNSUBSCRIBE removes the subscription.

SUBSCRIBE Packet

• Topic Filter: May include wildcards like device/+/status.
• Requested QoS: The QoS level the client wishes to receive.

SUBACK Packet

• Contains Reason Codes for each topic filter, indicating if the subscription was granted.

UNSUBSCRIBE Packet

• Indicates which topic filters the client no longer wants.

UNSUBACK Packet

• Similar to SUBACK, includes Reason Codes for each topic filter unsubscribed.

SUBSCRIBE & UNSUBSCRIBE Sequence Diagram

‍

‍

• Properties can include Subscription Identifiers in MQTT 5.0, enabling more advanced subscription management.
• Reason Codes allow the broker to provide specific feedback (e.g., 0x8F for “Not authorized”).

‍

‍

6. PINGREQ & PINGRESP

To maintain an active network connection, the client must send a PINGREQ if it hasn’t transmitted anything within the keep-alive interval. The broker replies with a PINGRESP. This ensures the connection remains valid on both sides.

PINGREQ & PINGRESP Sequence Diagram

• Useful for detecting dead connections or network timeouts.
• Contains no payload or additional properties in standard use.

‍

‍

7. DISCONNECT

When a client or broker wants to end the connection, a DISCONNECT packet is sent. MQTT 5.0 extends this packet with additional properties, such as Session Expiry Interval (so the broker can discard or preserve session data accordingly).

DISCONNECT Packet

• Reason Code: Explains why the disconnection is happening (normal shutdown, bad credentials, etc.).
• Session Expiry Interval: If set to zero, the session is discarded immediately.

DISCONNECT Sequence Diagram

‍

‍

‍


8. AUTH (Enhanced Authentication Flows)

MQTT 5.0 introduces the AUTH packet for more advanced authentication and challenge/response schemes. While the classic CONNECT approach with username/password is still supported, AUTH enables step-by-step negotiations for scenarios like OAuth 2.0 or SASL.

AUTH Packet

• Auth Method: The authentication method agreed upon (e.g., SCRAM-SHA-256).
• Auth Data: Challenge or response data (depending on the auth step).
• Reason Code: Indicates success, re-auth needed, or failure.

AUTH Sequence Diagram (Example Challenge-Response)

‍

‍


This packet exchange can repeat until the authentication flow completes or fails.

‍

‍

9. Putting It All Together in Coreflux MQTT v5.0

Coreflux MQTT v5.0 fully supports these packet types and properties:

1. Message Expiry Interval: Prevent stale messages with a simple property setting.
2. Enhanced Subscription Management: Use subscription identifiers and user properties for fine-grained control.
3. Reason Codes & User Properties: Detailed feedback to clients and flexible metadata exchange.
4. Advanced Auth: Implement secure challenge-response flows without custom hacks.
5. Session Management: Tailor session expiry intervals to optimize resource usage.

These features enable IoT architects to build robust, scalable, and secure messaging solutions, whether for consumer-facing applications or industrial deployments.

‍

‍

Conclusion

MQTT 5.0 significantly expands the functionality and control over MQTT messaging. Coreflux MQTT v5.0 leverages these improvements to offer:

• Fine-tuned message handling via properties like Message Expiry Interval.
• Better error reporting and debugging with Reason Codes.
• Scalable, secure authentication mechanisms through AUTH packets.

By understanding each packet type—CONNECT, PUBLISH, SUBSCRIBE, PINGREQ, DISCONNECT, AUTH—and the associated MQTT 5.0 features, you’ll be well-equipped to design next-level IoT solutions.

‍

‍

Ready to Dive Deeper?

If you have any questions on setting up Coreflux MQTT v5.0, or need help with designing secure and efficient IoT architectures, reach out to our team. We’re here to help you harness the power of MQTT 5.0 for your unique use case.

‍

‍