Skip to content
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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

Abestanis
Copy link

This attempts to reduce the likelihood of the problem described in #540, but unfortunately doesn't completely fix it.

  • For every data we sent via the Modbus TCP socket we now wait for the drain event of the previous data in the hopes that the new data does not get merged into the same TCP frame.
  • We set the 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.

ports/tcpport.js Outdated Show resolved Hide resolved
@yaacov
Copy link
Owner

yaacov commented Sep 3, 2024

hi, thank you for the pull request 💚
I added a suggestion, can you take a look ?

@Abestanis Abestanis force-pushed the feature/reduce_multiple_apus_per_tcp_frame branch 2 times, most recently from e4ade68 to 27960f6 Compare September 3, 2024 09:35
@Abestanis Abestanis force-pushed the feature/reduce_multiple_apus_per_tcp_frame branch from 27960f6 to 1b6479c Compare September 3, 2024 15:15
@yaacov
Copy link
Owner

yaacov commented Sep 8, 2024

LGTM, can you make the tests not fail ?

@Abestanis
Copy link
Author

LGTM, can you make the tests not fail ?

The tests seem to assume that a call to write will set the _buffer directly, but because write is called in a the finally handler, this is no longer the case.

I'm not too familiar with javascript testing, could you please give me some pointers on how to approach this?

@Abestanis
Copy link
Author

Any hints on how to fix the tests would be appreciated.

@yaacov
Copy link
Owner

yaacov commented Dec 16, 2024

Any hints on how to fix the tests would be appreciated.

When running locally, does the error msgs makes sense to you ?
Did you identify the failing test on your local dev environment ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants