Drop-resistant TCP proxy (with automatic reconnects)

Question

Computer networks

Suppose there is a server and some client. The client connects to the server via TCP. At the same time, the client really does not like it when the connection breaks: due to his imperfection, he believes that the connection, once established, never breaks, and if it still breaks, then consider that he dies, and you have to do all the work again.

Isn't there some ready-made utility that organizes a "logically break-resistant" pseudo-connection between the client and the server? Here's how it could work:

                                             |
                                             |
                                             |
CLIENT ----> localhost:1234 | server:1234 -----> SERVER
                 daemonC <=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+> daemonC
                           if it breaks here, then the utility daemon
                           on the client reconnects to the daemon
                           utilities on the server, but, what is important, when
                           This CLIENT does not consider that the connection
                           with the SERVER was broken, because CUSTOMER
                           connected to a daemon on the localhost (and
                           SERVER, respectively, also with a demon
                           on his host).

Those. the idea is that even if the connection is broken for a day (they turned off and replaced the router, changed the provider - anything at all), the CLIENT still continues to consider that it is connected to the SERVER, and there was no disconnect (but the connection suddenly became very, very inhibitory - skips 1 packet a day). With a localhost, the connection never breaks ...

PS
Please do not suggest any TCP keep-alive, timeouts at the TCP level and other rubbish - the solution here should obviously be at a higher level than TCP (because to force TCP- the connection is not interrupted in the event, for example, of a physical replacement of the router or moving to another Internet operator is impossible). Also, there is no way to make improvements in the client and server.

Answer 1

Please do not suggest any TCP keep-alives, timeouts at the TCP level, and other rubbish - the solution here should obviously be at a higher level than TCP (because to force the TCP connection not to break in the case, for example, of a physical replacement router or moving to another Internet operator is not possible). Also, there is no way to make improvements in the client and server.

Just here a raised vpn server on the server and a client on the client can help (or vice versa, it doesn’t matter), the connection should be established accordingly already in this local network. At least short-term breaks in communication (changed the routing table on the server, openvpn reconnected, connections did not break), but in the long run, I just xs, what other factors can interfere.

Answer 2

The only way out is to write it yourself. The logic of restoring connection to the server is a unique thing. And if in fact there is no connection, then it was better to just use UDP. Well, yes, and writing a proxy in this case is not at all difficult.

Answer 3

Unfortunately, not everything is as simple as it seems. In an arbitrary case for arbitrary application protocols, this problem is not reliably solved. Suppose I implement a similar proxy. The TCP connection was broken on some send() operation. How can I know if I need to resend the data that was in this send() or not? Those. here it is really better to use, for example, UDP and write some kind of your own transport on top of UDP, which will be resistant to long disconnections.

Answer 4

And you are sure. that the server and client do not exchange ping packets? That is, the client (server) sends a packet to the server (client) and, if it does not receive a response within a specified interval, disconnects.

Answer 5

Try stunnel, it seems to work fine. I just don't remember. whether it is possible to raise an unencrypted channel on it. Well, if it is not possible to deliver software to the server, you will have to install another machine in front of the server. Well, it looks like it should help.