Library: MQTT-SN Client library Gateway Search Support #80021

SpontaneousDuck · 2024-10-17T17:17:34Z

This pull requests extends the MQTT-SN Client library to support the "Gateway Advertisement and Discovery" process defined in section 6.1 of the MQTT-SN specification. This includes breaking changes to the transport interface and the default included UDP interface implementation as support for UDP multicast messages is added as implemented by the Paho MQTT-SN Gateway (link).

This PR closes issue #78010.

Changes List:

github-actions · 2024-10-17T17:18:15Z

Hello @SpontaneousDuck, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

rlubos

Thanks for the contribution, some initial feedback from my side. Looks pretty neat overall.

samples/net/mqtt_sn_publisher/prj.conf

samples/net/mqtt_sn_publisher/src/udp.c

subsys/net/lib/mqtt_sn/mqtt_sn_transport_udp.c

rlubos · 2024-10-23T14:18:36Z

subsys/net/lib/mqtt_sn/mqtt_sn.c

+	char addr[CONFIG_MQTT_SN_LIB_MAX_ADDR_SIZE];
+	size_t addr_len;


What's the expected address format? What byte order?

I was expecting the addresses to be agnostic to the library and it would only store the address and pass pointers back to the transport code the user creates. Does the byte order matter then?

Sure, but the address format for a specific transport should still be known for the application, I'm not sure if it's documented anywhere right now.

I could add some documentation to that that the user will need to define this based on their implemented transport?

That would be nice.

subsys/net/lib/mqtt_sn/Kconfig

rlubos · 2024-10-23T14:26:21Z

tests/net/lib/mqtt_sn_client/src/mqtt_sn_client.c

 	zassert_equal(err, 0, "unexpected error %d");
 	zassert_equal(client->state, 1, "Wrong state");
 	zassert_equal(evt_cb_data.called, 1, "NO event");
 	zassert_equal(evt_cb_data.last_evt.type, MQTT_SN_EVT_CONNECTED, "Wrong event");
 	k_sleep(K_MSEC(10));
 }

-static ZTEST(mqtt_sn_client, test_mqtt_sn_connect_no_will)
+static ZTEST(mqtt_sn_client, test_mqtt_sn_handle_advertise)


New test cases could be in a separate commit.

rlubos · 2024-10-23T14:26:44Z

samples/net/mqtt_sn_publisher/compose/README.md

@@ -0,0 +1,6 @@
+This folder contains an example MQTT-SN Gateway made for use with a native_sim board application utilizing MQTT-SN.


Same here, convenience configs could be introduced in a separate commit.

tests/net/lib/mqtt_sn_client/src/mqtt_sn_client.c

jukkar · 2024-10-23T15:26:40Z

subsys/net/lib/mqtt_sn/mqtt_sn_transport_udp.c

@@ -43,25 +44,65 @@ static int tp_udp_init(struct mqtt_sn_transport *transport)
 {
 	struct mqtt_sn_transport_udp *udp = UDP_TRANSPORT(transport);
 	int err;
+	struct sockaddr_in addrm;


So no IPv6 support?

Not currently in the provided implementation but that matches the current implementation that I am extending. This does not preclude the user from implementing their own transport that uses IPv6. Should I add support as part of this PR or leave the current implementation's limitation?

As the other parts of the Zephyr network stack typically support IPv6 and IPv4 (dual stack), it would be preferable if all new code also support dual stack. So yes, I would prefer IPv6 support also in this PR.

Added IPv6 support I believe with a switch at the two places it matters.

subsys/net/lib/mqtt_sn/mqtt_sn_transport_udp.c

SpontaneousDuck · 2024-10-23T20:38:20Z

What would be the recommended way to add changes based on code comments? It appears like the desired commits to merge will be all the code changes in one commit with test cases and convenience commits in different commits (3 total). Is this incorrect and I can add the requested changes in another commit? Or should I git reset and git push --force to get the desired number of commits which will break the comments left on this PR? I have a bunch of changes due to above comments but am not sure what the recommended way to push them to the tree is.

rlubos · 2024-10-24T07:45:39Z

What would be the recommended way to add changes based on code comments? It appears like the desired commits to merge will be all the code changes in one commit with test cases and convenience commits in different commits (3 total). Is this incorrect and I can add the requested changes in another commit? Or should I git reset and git push --force to get the desired number of commits which will break the comments left on this PR? I have a bunch of changes due to above comments but am not sure what the recommended way to push them to the tree is.

Typically you just squash the review fixes into original commits (you can use git commit --fixup <original commit SHA> and then interactive reabase with --auto-squash option).

As for splitting the changes into separate commits, I guess the easiest would be to git reset and then create separate commits.

And yes, you'd need to force-push as the history is rewritten, but that's a common thing to do in Zephyr PRs. Don't worry about review comments, GH will handle this.

Fixes: zephyrproject-rtos#78010 This commit implements the "Gateway Advertisement and Discovery" process defined in section 6.1 of the MQTT-SN specification. This includes breaking changes to the transport interface and the default included UDP interface implementation as support for UDP multicast messages is added as implemented by the Paho MQTT-SN Gateway. Signed-off-by: Kenneth Witham <[email protected]>

Fixes: zephyrproject-rtos#78010 This commit adds tests for the "Gateway Advertisement and Discovery" process. This includes tests for handling SEARCHGW, GWINFO, and ADVERTISE as well as manually adding a Gateway for use. Gateway pruning when missing ADVERTISE messages is also tested. Signed-off-by: Kenneth Witham <[email protected]>

Fixes: zephyrproject-rtos#78010 This commit adds the "Gateway Advertisement and Discovery" process to the MQTT-SN Publisher Sample application. Signed-off-by: Kenneth Witham <[email protected]>

SpontaneousDuck · 2024-10-24T20:34:42Z

Ok, I think I made it through all the comments and pushed all the changes up in 3 new commits. One for main code and doc changes, one with unit tests, and one with the sample code updates.

SpontaneousDuck force-pushed the mqttsn_gw_78010 branch 3 times, most recently from 146ac49 to e2ca93a Compare October 21, 2024 20:19

SpontaneousDuck marked this pull request as ready for review October 22, 2024 14:32

zephyrbot added area: Networking area: Samples Samples labels Oct 22, 2024

zephyrbot requested review from jukkar, kartben, nashif, pdgendt, rlubos, ssharks and tbursztyka October 22, 2024 14:33

zephyrbot assigned rlubos and jukkar Oct 22, 2024

rlubos reviewed Oct 23, 2024

View reviewed changes

jukkar reviewed Oct 23, 2024

View reviewed changes

SpontaneousDuck force-pushed the mqttsn_gw_78010 branch from e2ca93a to 50e046c Compare October 24, 2024 19:59

SpontaneousDuck added 3 commits October 24, 2024 13:25

net: mqtt-sn: Update MQTT-SN Publisher Sample with Gateway Discovery

b92b926

Fixes: zephyrproject-rtos#78010 This commit adds the "Gateway Advertisement and Discovery" process to the MQTT-SN Publisher Sample application. Signed-off-by: Kenneth Witham <[email protected]>

SpontaneousDuck force-pushed the mqttsn_gw_78010 branch from 50e046c to b92b926 Compare October 24, 2024 20:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Library: MQTT-SN Client library Gateway Search Support #80021

Library: MQTT-SN Client library Gateway Search Support #80021

SpontaneousDuck commented Oct 17, 2024

github-actions bot commented Oct 17, 2024

rlubos left a comment

rlubos Oct 23, 2024

SpontaneousDuck Oct 23, 2024

rlubos Oct 23, 2024

SpontaneousDuck Oct 23, 2024

rlubos Oct 24, 2024

rlubos Oct 23, 2024

rlubos Oct 23, 2024

jukkar Oct 23, 2024

SpontaneousDuck Oct 23, 2024

jukkar Oct 24, 2024

SpontaneousDuck Oct 24, 2024

SpontaneousDuck commented Oct 23, 2024 •

edited

Loading

rlubos commented Oct 24, 2024

SpontaneousDuck commented Oct 24, 2024

		char addr[CONFIG_MQTT_SN_LIB_MAX_ADDR_SIZE];
		size_t addr_len;

		@@ -0,0 +1,6 @@
		This folder contains an example MQTT-SN Gateway made for use with a native_sim board application utilizing MQTT-SN.

Library: MQTT-SN Client library Gateway Search Support #80021

Are you sure you want to change the base?

Library: MQTT-SN Client library Gateway Search Support #80021

Conversation

SpontaneousDuck commented Oct 17, 2024

github-actions bot commented Oct 17, 2024

rlubos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SpontaneousDuck commented Oct 23, 2024 • edited Loading

rlubos commented Oct 24, 2024

SpontaneousDuck commented Oct 24, 2024

SpontaneousDuck commented Oct 23, 2024 •

edited

Loading