Reduce the chances of multiple Modbus APUs per TCP frame

[Abestanis]

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.

[yaacov]

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

[yaacov]

LGTM, can you make the tests not fail ?

[Abestanis]

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]

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

[yaacov]

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 ?

[Abestanis]

The error message did make sense to me, in all cases it's because the tests were expecting the write to have an immediate effect and not waiting for the new promise. Once I realized that I could just attach and wait for the private internal write promise in the test it became clear how to fix them. They pass locally now, let's hope CI is also happy.