[TCP] Apply IPv4 socket options to accepted sockets in modbus_tcp_accept#850
Open
NeriaIfrah wants to merge 1 commit into
Open
[TCP] Apply IPv4 socket options to accepted sockets in modbus_tcp_accept#850NeriaIfrah wants to merge 1 commit into
NeriaIfrah wants to merge 1 commit into
Conversation
modbus_tcp_accept() did not call _modbus_tcp_set_ipv4_options() on the accepted socket, leaving Nagle's algorithm enabled and missing the IPTOS_LOWDELAY TOS marking on the server side. This created an asymmetry with the client connect path, where the same helper is already called after socket() and before connect(). With Nagle active on the server, the interaction with the peer's Delayed ACK mechanism (up to 40 ms per RFC 1122) can introduce latency in response delivery, which is undesirable in Modbus TCP where real-time response is a protocol expectation. The lack of IPTOS_LOWDELAY on responses also means server-side traffic does not receive low-latency prioritisation in QoS-aware infrastructure. Call _modbus_tcp_set_ipv4_options() on the accepted socket right after the FD_SETSIZE check, mirroring the client connect path. On failure, the socket is closed and the function returns -1, matching the existing error-handling style in the same function. The helper already contains the required platform guards (#ifndef OS_WIN32 for IP_TOS, !SOCK_NONBLOCK for FIONBIO), so no additional preprocessor logic is needed at the call site. Closes stephane#849
|
We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please fill https://forms.gle/5635zjphDo5JEJQSA to get added. Your document will be manually checked by the maintainer. Be patient... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #849.
modbus_tcp_accept()did not call_modbus_tcp_set_ipv4_options()onthe accepted socket, leaving Nagle's algorithm enabled and missing the
IPTOS_LOWDELAYTOS marking on the server side. This created anasymmetry with the client connect path.
Change
A single call to
_modbus_tcp_set_ipv4_options(ctx->s)is added inmodbus_tcp_acceptimmediately after theFD_SETSIZEvalidation. Onfailure the socket is closed and the function returns -1, matching the
existing error-handling style in the same function. The helper already
contains the necessary platform guards, so no additional preprocessor
logic is needed at the call site.
Scope
This PR intentionally addresses only the IPv4 path (
modbus_tcp_accept).The IPv6 / protocol-independent path (
modbus_tcp_pi_accept) is leftfor a follow-up, since the helper is IPv4-only (it sets
IPPROTO_IP/IP_TOS) and the IPv6 case needs a slightly different approach.