Background:
We have a client/server application that uses a persistent connection to the server.
Benchmarks show that it is many times faster to use an already open connection rather than spend significant time (2.5 seconds) setting up a new connection (crypto).
Unfortunately, the old connection may be stale.
Is there a way to wait for the system-level result of sending a message [either ACK or error]?
Waiting for read and then getting the end of stream causes confusion.
I know the message might be broken up into packets. It would suit my purposes equally well to know either if any part of the message was acked or if all of it was. The interesting problem here is stale connection.
In which case you will get an exception when writing to it, eventually.
No.
Confusion to whom? It’s the code’s job to handle confusion. If you get an unexpected EOS the peer has closed the connection, or an intermediate firewall has, in which case you have to deal with it.
Completely irrelevant. You don’t have any control over that or any visibility of it either. What you get is a byte stream terminated by EOS or an exception.
No it wouldn’t. The ACK only means it has got as far as the peer’s TCP/IP stack. What your application is interested in is whether it has gotten into the peer application, and only the peer application can tell you that, via an application-protocol-level ACK. TCP/IP ACKs are of no help here.
And that’s a rather trivial problem. You can detect it in code and you can deal with it ditto. Database vendors have been doing this stuff for decades. Not rocket science, and nothing that requires knowledge of the TCP ACKs.