Option to configure TCP no_delay

[FedorSmirnov89]

• extended NetworkOptions by an optional nodelay flag
• the flag is used when setting up the socket used for the tcp connection
• provided an example of how the async client can be configured to set nodelay

Type of change

• New feature (non-breaking change which adds functionality)

Description

This pull request adds an option to set the nodelay flag for the TCP connection in the MQTT client. The nodelay flag, when enabled, disables Nagle's algorithm, which can help reduce latency by sending packets immediately without waiting for a full buffer. This is particularly useful in scenarios where low latency is critical.

Changes

• Added a new configuration option to the MQTT client to enable or disable the nodelay flag for the TCP connection to the broker.
• Updated the provided examples to include instructions on how to use this new option.

Issue

• addresses Issue Option to set the tcp-nodelay flag used for the connection from the MQTT client to the broker #871

Checklist:

• Formatted with cargo fmt
• Make an entry to CHANGELOG.md if it's relevant to the users of the library. If it's not relevant mention why.

[de-sh]

Just a few suggestions...

[coveralls]

Pull Request Test Coverage Report for Build 9258539470

Details

• 2 of 5 (40.0%) changed or added relevant lines in 2 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.001%) to 36.134%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
rumqttc/src/lib.rs	1	4	25.0%

Files with Coverage Reduction	New Missed Lines	%
rumqttc/src/eventloop.rs	1	83.91%

Totals
Change from base Build 9193063302:	0.001%
Covered Lines:	5977
Relevant Lines:	16541

---

💛 - Coveralls

[swanandx]

PR look good, thanks for the contribution!

just one question before merging:
have you tried comparing the actual performance difference with & without this flag? because if latency is bottle-necked by eventloop or some other thing, this might not be that boost right? please correct me if wrong

thanks :)

[de-sh]

have you tried comparing the actual performance difference with & without this flag? because if latency is bottle-necked by eventloop or some other thing, this might not be that boost right? please correct me if wrong

I believe OP is trying to use rumqttc in time critical applications where the messages they are trying to send aren't enough for nagling to be the right approach. We can safely provide this as an opt-in.

[de-sh]

Congrats on the merge @FedorSmirnov89 🎊

[FedorSmirnov89]

Thank you for merging :) . Just to add the information @swanandx was asking about: It's exactly as @de-sh said: We have a distributed application where two clients on different nodes exchange messages. We measured the timing of the messages since we want them to have as little latency and jitter as possible. They are exchanging very small messages on a high frequency (range of 1-4 ms).

Seeing that configuring the broker (we are using the normal Mosquitto which comes with an apt-get in Linux) to set no-delay for the messages it is sending significantly reduced the jitter, we did the same thing on the client side by building our agents of a local branch of rumqttc where we had the no-delay option enabled. Again, we saw a significant decrease in message jitter.

Thanks a lot for reviewing and merging :) . We can now go back again to building off the main branch of the repository which is great 😄