Reduce the chances of multiple Modbus APUs per TCP frame #564
Conversation
This file contains 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
yaacov
reviewed
Sep 3, 2024
|
hi, thank you for the pull request 💚 |
Abestanis
force-pushed
the
feature/reduce_multiple_apus_per_tcp_frame
branch
2 times, most recently
from
e4ade68
to
27960f6
Compare
Abestanis
force-pushed
the
feature/reduce_multiple_apus_per_tcp_frame
branch
from
27960f6
to
1b6479c
Compare
yaacov
reviewed
Sep 8, 2024
|
LGTM, can you make the tests not fail ? |
The tests seem to assume that a call to I'm not too familiar with javascript testing, could you please give me some pointers on how to approach this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This attempts to reduce the likelihood of the problem described in #540, but unfortunately doesn't completely fix it.
drainevent of the previous data in the hopes that the new data does not get merged into the same TCP frame.NoDelayflag.Both changes seem to reduce the amount of TCP frames with more than one Modbus APU, but under very high throughput the can still be some of them. There seems to be no way of guaranteeing separate TCP packages short of using a raw socket and implementing the entire TCP stack manually, so I personally think this is a design flaw of the Modbus protocol and in the end I choose to fix the problem on the Modbus server side by accepting TCP packages with multiple APUs. Also, all other Modbus implementation which I found that were not written for bare metal have exactly the same problem.
I'm posting this here in case you still want to have an improvement over the current state. Sorry about all the whitespace changes, that was the auto formatter of my IDE.