Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MQTTv5 Implementation #316

Draft
wants to merge 127 commits into
base: mqttv5-dev
Choose a base branch
from
Draft

MQTTv5 Implementation #316

wants to merge 127 commits into from

Conversation

adituc
Copy link

@adituc adituc commented Mar 11, 2025

Upgrading MQTT Library to support both v3.1.1 and v5 features

Description

  • This change adds the client implementation of MQTT version 5 CONNECT, CONNACK, Outgoing PUBLISH, PUBLISH ACKS, Incoming PUBLISH, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, DISCONNECT.
  • Existing data structures and functions are modified, and some new functions are added to serialize and deserialize the packets.

Test Steps

  • Unit Tests are added for all new and modified features.
  • Unit Tests for MQTTv5 functions are added in a separate folder in test.

Checklist:

  • I have tested my changes. No regression in existing tests.
  • I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@DakshitBabbar DakshitBabbar changed the base branch from main to mqttv5-dev March 18, 2025 04:45
@DakshitBabbar DakshitBabbar marked this pull request as ready for review March 18, 2025 04:46
@DakshitBabbar DakshitBabbar marked this pull request as draft March 18, 2025 06:06
@@ -74,6 +74,14 @@
*/
#define CORE_MQTT_SERIALIZED_LENGTH_FIELD_BYTES ( 2U )

#define UINT8_SET_BIT( x, position ) ( ( x ) = ( uint8_t ) ( ( x ) | ( 0x01U << ( position ) ) ) )
#define UINT16_HIGH_BYTE( x ) ( ( uint8_t ) ( ( x ) >> 8 ) )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good if we added comments at the top of these macros explaining in breif waht they do. Similar to how it is done for other similar macros.

/**
* @brief Get the 4th byte of a 32-bit unsigned integer.
*/
#define UINT32_BYTE3( x ) ( ( uint8_t ) ( ( x ) >> 24 ) )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any specific reason why we did not choose to use a macro like: UINT32_GET_BYTE( x, byteNumber ) = ( ( uint8_t ) ( ( x ) >> 8 * byteNumber ) ) but made separate macros for every byte position?

/**
* @ingroup mqtt_constants
* @brief The size of MQTT PUBACK, PUBREC, PUBREL, and PUBCOMP packets with reason code, packet id.
*/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: Indentation of the comments needs to be rectifed.

/**
* @brief Struct used to deserialize the will properties.
*
**/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be a copy-pasted comment from the WillPropertiesVector struct. Please correct the description of this struct accordingly.

@@ -347,7 +576,7 @@ static MQTTStatus_t handleKeepAlive( MQTTContext_t * pContext );
*
* @return MQTTSuccess, MQTTIllegalState or deserialization error.
*/
static MQTTStatus_t handleIncomingPublish( MQTTContext_t * pContext,
MQTTStatus_t handleIncomingPublish( MQTTContext_t * pContext,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that this function is used just in this file. Is there any specific reason why we made it non-static?

/**
* @brief Utf 8 encoded string has 2 byte length field and 1 byte property id.
*/
#define MQTT_UTF8_LENGTH_SIZE ( 3U )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good if we keep all the macro definitions in one place. Consider moving these macro definitions above the function declarations where all the macros are defined.

* @param[out] pProperty To store the decoded property.
* @param[out] pPropertyLength Size of the length.
* @param[out] pUsed Whether the property is decoded befire.
* @param[out] pIndex Pointer to the current index of the buffer.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rectify the out/in types for the parameters in the description, fix typo for "before" in the third param and make the description of the first param clearer (I suppose it was supposed to be "Pointer to store the decoded property"). Similarly for other such decode functions.

const MQTTSubscribeInfo_t * pSubscriptionList,
size_t subscriptionCount,
uint16_t packetId );

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the function is not used anymore remove its descriptions as well.

packetSize = 1U + remainingLengthEncodedSize( remainingLength )
+ remainingLength;
connectPacketSize += propLen;
connectPacketSize += remainingLengthEncodedSize(propLen);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider changing the name of this function to variableLengthEncodedSize?

* 268,435,455 - max remaining length according to spec MQTT-v5;
*
* */
if( remainingLength > MQTT_MAX_REMAINING_LENGTH )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can add a comment here - "It is possible that the remaining length becomes more than the maximum allowed by the MQTTV5-Spec, i.e. 268,435,455. This is because the user may enter a large number of user properties for the connect packet and/or the last will. Hence we need to have a check for this case."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants