How to handle network disruption and overcoming it without losing data?

Question

I am experimenting with Netty which is an asynchronous event-driven network application framework. In my application, suppose a server and a client are sending messages each other in a chatting application. Suddenly a client was disconnected from its network because of WiFi being unavailable. The server being unaware of it, continues sending messages to the client. But the client is unable to receive those. How to handle this ? The messages sent from server are important.

Answer 1

Sounds like your question has a couple parts to it.

1) Detect when the peer is disconnected.

See https://stackoverflow.com/a/26520444/3993966

2) How to handle the data that was sent before being notified of the peer is disconnected.

This is application dependent and depends on your requirements. There are many different ways to accomplish this and varying complexities for each approach. Below is just a couple approaches and some simplistic pros/cons for each.

2.1) Do nothing.

If it is a user to user application perhaps it is an acceptable trade off to assume the user will come back online and ask what they missed.

+ Simple

- Relying on "smart" clients to figure out what they missed

2.2) Application level message acknowledgement.

The server will save all application messages until the client acknowledges it has received the message.

+ Your clients will always get their messages

- Extra round trip for every message

- Server must maintain extra state for every client

- Sever must maintain a queue of unacknowledged messages for each client (may have to cache to disk to avoid running out of memory, may need timeouts on data, the storage policy can get complicated)

- Must be able to uniquely identify clients across socket connections (to deliver any "unreceived" messages)

- If your application is a peer-to-peer chat it may require a third party (for example google chat) to play the role as server (or generally be more complicated in other ways).

Answer 2

You write that the messages sent from the server are important. So I assume that you want to ensure that the messages not only arrive at the client computer but are also displayed/processed/stored by the client application.

Even if your server code accesses the TCP ACK information on the server side, that only tells you that the data was processed by the client computer's TCP stack, not the application. The client application code needs to send acknowledgements to the server that it has received and processed the message. If the server application code doesn't receive an ack from the client app in a certain amount of time, it should retransmit the message. This means that the client app needs to handle duplicate messages that may come as a result of being retransmitted. It would do this by sending an ack and then dropping the message.