Thank you, that helps a lot.
Since TCP is at least an order of magnitude if not more faster than our slow CANbus, I suspect that writing to the TCP send queue and reporting back the number of bytes written probably happens in a matter of microseconds for a total of 22 bytes. Therefore if it times out in 6ms there is already something wrong, indicating don't write anymore data to the queue until whatever is wrong is fixed.
Three questions;
- How big is the send queue?
- When the number of bytes written is returned by client.write(), does that mean written and received by the other side? Or just written to the send queue?
- when you say
how long is the timeout? How long is the wait for ACK before it errors out, and when it errors out is this when client.connected() fails? Or is some other error thrown?
I was looking at UDP for the very reason that it is recommended for time critical applications but it appears really daunting as all of the "automagic" buried in TCP is now left up to the programmer. It has been my understanding that TCP takes the complexity out of UDP. I'm a little leery of going down a rabbit hole I might not be able to get out of.
I did find this relatively easy to understand example by @ScruffR and @rickkas7
but I have no idea what kind of handshaking and error checking is going to be involved to make it a robust alternative. When TCP works it's awesome, when it breaks it's a bit of nightmare.
Thanks,
Joerg