Skip to content

Express the need of a non-blocking TransportRecv_t #318

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.

Sign up for GitHub

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

Merged
rohitmadan07 merged 5 commits into from
Apr 7, 2025
Merged

Express the need of a non-blocking TransportRecv_t #318

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a98ccc4
Expressed the need for a non blocking transport_recv
jadaber Apr 4, 2025
0b3ab6d
used uncrustify to format code accordingly
jadaber Apr 4, 2025
b65868c
Integrate idea of DakshitBabbar
Apr 7, 2025
8e8c1fa
Uncrustify: triggered by comment.
actions-user Apr 7, 2025
130866a
Trigger CI Checks
DakshitBabbar Apr 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/doxygen/porting.dox
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,8 @@ struct NetworkContext {
};
@endcode

Please note that it is HIGHLY RECOMMENDED that the transport receive implementation does NOT block.

@section mqtt_porting_time Time Function
@brief The MQTT library relies on a function to generate millisecond timestamps, for the
purpose of calculating durations and timeouts, as well as maintaining the keep-alive mechanism
Expand Down
4 changes: 4 additions & 0 deletions source/interface/transport_interface.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,6 +96,7 @@
* without TLS, it is typically implemented by calling the TCP layer receive
* function. @ref TransportRecv_t may be invoked multiple times by the protocol
* library, if fewer bytes than were requested to receive are returned.
* Please note that it is HIGHLY RECOMMENDED that the transport receive implementation does NOT block.
* <br><br>
* <b>Example code:</b>
* @code{c}
Expand Down Expand Up @@ -200,6 +201,9 @@ typedef struct NetworkContext NetworkContext_t;
* coreMQTT will continue to call the transport interface if it receives
* a partial packet until it accumulates enough data to get the complete
* MQTT packet.
Copy link
Member

@DakshitBabbar DakshitBabbar Apr 7, 2025

Choose a reason for hiding this comment

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

I was wondering if it would be better to include the fact that the user can also implement their own keep alive mechanism in which case the non-blocking receive function may/may not affect the keep alive mechanism. Something like this:

/*
 * @note It is HIGHLY RECOMMENDED that the transport receive
 * implementation does NOT block.
 * coreMQTT will continue to call the transport interface if it receives
 * a partial packet until it accumulates enough data to get the complete
 * MQTT packet. 
 * A non‐blocking implementation is also essential so that the library's inbuilt 
 * keep‐alive mechanism can work properly, given the user chooses to use 
 * that over their own keep alive mechanism.
 */

Let me know what you think.

Copy link
Contributor Author

@jadaber jadaber Apr 7, 2025

Choose a reason for hiding this comment

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

Yes that's perfect I think!

* A non‐blocking implementation is also essential so that the library's inbuilt
* keep‐alive mechanism can work properly, given the user chooses to use
* that over their own keep alive mechanism.
*
* @param[in] pNetworkContext Implementation-defined network context.
* @param[in] pBuffer Buffer to receive the data into.
Expand Down
Loading