-
-
Notifications
You must be signed in to change notification settings - Fork 242
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.
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
Reduce the chances of multiple Modbus APUs per TCP frame #564
base: master
Are you sure you want to change the base?
Reduce the chances of multiple Modbus APUs per TCP frame #564
Conversation
hi, thank you for the pull request 💚 |
e4ade68
to
27960f6
Compare
27960f6
to
1b6479c
Compare
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? |
Any hints on how to fix the tests would be appreciated. |
When running locally, does the error msgs makes sense to you ? |
This attempts to reduce the likelihood of the problem described in #540, but unfortunately doesn't completely fix it.
drain
event of the previous data in the hopes that the new data does not get merged into the same TCP frame.NoDelay
flag.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.