using same tcpclient for reading/writing and keeping it alive

Question

I have the following situation:
Client -> router -> Internet -> Dedicated server

Client: On startup, connects to server and keeps connection open. Occasionally receives notifications from the server that files are changed . Starts a sync process, and afterwards notifies the server if this was successfull. May lose its connection at times, so a new connection must be made then.

Server (internet): Contains files which sometimes are changed. Accepts incoming clients, and keeps the tcpclient object for that client. It can never connect directly with a client, because the client sits behind several routers; that's the reason why the connection must be kept open. Notifies the client(s) when a change is made. And also checks for each client for a sync successful message.

Questions:

1. How do I effectively keep my connection open on the client and server side?

2. What happens when the client wants to notify the server that the sync process was a success, but at the meantime the server notifies for client for a new update..?

3. Is it a good practice to just create a Tcpclient (client-side) and keep this object throughout the whole program? And when some network operation failed, try to connect with this tcpclient object again?

I did a lot research but couldn't really find something that keeps using the same tcpclient..

Btw: This is a new thread based on my previous post, were this solution (reuse tcpclient) was proposed(udp packet not coming through)

Greets Daan & thanks in advance for your attention

Answer 1

How do I effectively keep my connection open on the client and server side?

TCP sendscan send keep alive messages per default if you activate SO_KEEPALIVE. But it can be a good idea to send your own keep alive messages (to prevent idle connection disconnect in routers etc)

What happens when the client wants to notify the server that the sync process was a success, but at the meantime the server notifies for client for a new update..?

Design your protocol so that is has a Request id and can differ between notifications and replies.

Design your API to be synchronous, but use asynchronous socket handling.

Is it a good practice to just create a Tcpclient (client-side) and keep this object throughout the whole program? And when some network operation failed, try to connect with this tcpclient object again?

Are you sure that it's possible to connect with the same client again? IIRC it's not possible with Socket and the same should apply to TcpClient

I would use the same client as long as it's not getting disconnected.