TCP Client/server best practice

[zilp]

It is easy to say this. In reality, it's a multi-billion corporation, with the related bureaucracy. When it comes to consumer protection laws, the one who sells it to the end customer is responsible. So the first one to take the hit is the sales company / installer, the one who is our direct customer because they install our products, too, and generate a lot of revenue for us! So do we tell the end customers: "demand a replacement [from our partner]". Then what - the inverters are otherwise working and being bought in hundreds - should our partner evaluate another brand, re-educate install staff to install those, and should we do the integration work for that new brand, and hope they don't have another bug? Or should they work with the manufacturer, acting as broken telephone?

If possible: Buy one yourself elsewhere, force them to fix it for you, then tell your customer to demand the same fix and resell yours.

So that is why we have to work simultaneously on two fronts, bypassing both the end-user and the seller (our customer) and communicating directly with the manufacturer (whose product we are interfacing with), and at the same time, try to work out if we can find any pattern in the failures. It could be a simple fix "don't do X, do Y instead" *, but finding it is indeed hard. But getting through to engineers in a large corporation isn't easy, either. Legal demands are guaranteed to not lead anywhere.

Well, you need to be able to reliably reproduce the problem, of course. Then, why would legal demands not lead anywhere?

But whatever we choose to do, it will be waste of time and money for us anyway, which is why I advise: when interfacing with black boxes outside of your control, keep away from stuff like modbus TCP if you can, and for any problem, use the simplest interface you can find.

That's good advice regardless, of course.

[zilp]

That is much easier said than done. Manufacturer will claim it works for them and then it is up to you to prove a product isn't standard compliant. Now try and find a standard on how a TCP/IP stack should behave with all the crutches (like Nagle's algorithm) that have been added to TCP/IP over the decades.

You only need the base TCP RFC, plus whatever the implementation on your own side supports (and isn't disabled). There are no backwards-incompatible changes to TCP, any compliant TCP implementation has to be able to talk to a TCP implementation compliant with only the original RFC. And further development of TCP was either extensions that are negotiated (and thus are not used unless both sides signal support), or just more specific rules for how one could do things to optimize for certain applications within the rules laid out by the original RFC (with Nagle's algorithm being an example of the latter - so, you don't need to know about Nagle's algorithm to check whether an implementation that uses it is violating the TCP spec).

[nctnico]

Again, easier said than done.

I have found this though: https://github.com/TheJokr/tcpreq It could be interesting to use in order to find possible problems in a TCP/IP stack. But I don't know how valid it is as a test suite to test conformance to the 'standard'. A lot rides on whether the RFCs are defining functionalities well enough to leave no room for interpretation. And even then there are implementations which just suck. The TCP/IP stack in Windows for example.