4 replies to this topic

[Didax]

Hi everyone,

 

I have programmed a PHP server that handles socket connections.

The system works perfectly, but sometimes a strange thing happens.

Users who have wireless connections remain freezed when their connection slows down or ends badly.

 

At first I thought it was a problem due to the fact that the server did not notice that the connection was dropped because the client did not send the RST signal.

Then I inserted a verification system on the server that sends a message to the client if there were no IO operations within a fixed interval.

 

If the client does not respond to this message then the server assumes that:

(1) the connection is dropped without sending the reset signal or (2) the connection is not dropped but is very slow.

Both in the case (1) that in the case (2) the socket is forced to be closed by the server.

 

For some clients the problem has been solved, but unfortunately there are still other clients that are blocked.

 

My question is: if the connection with the client did not fall but it's just slowed down (which is often the case with wireless), what happens if suddenly the connection is resumed?

 

The scenario should be this:

- The client slows

- Server sends the control message

- The client does not receive it in time

- The server closes the connection brutally

- The client resumes the connection but did not receive the reset signal

 

is it possible?

how can I solve?

[nife87]

This is just an idea, so please inform me if it is totally misplaced  
Even though the speed is slowed, time is not, so the client should be able to detect that time gap/leap and drop the connection itself after a fixed time interval without signal. The key is that the server's time interval must be a little larger to accommodate clients clients wanting to resuming (without luck) after an interval close to their time limit.
For instance, where X is some time interval (the 1.5 is probably way too much, depending on X itself it may be smaller, but you get the idea):
ClientDropTime = X
ServerDropTime = X * 1.5

[hplus0603]

If you need to use TCP, then you have to live with the fact that a lossy connection will kill throughput.
Similarly, some routers will "forget" about TCP connections if too much is going on, or it's idle for too long.
You could set up a system of keepalives/heartbeats. Send a heartbeat in each direction every 1 seconds. If one of the sides hasn't seen a heartbeat for 5 seconds, assume the other end is gone, close the socket, and try to re-open a new connection (if on the client) or just close the socket on the server.

Another option is to use UDP, although you'll need the heartbeat anyway.

[Didax]

Thanks for the replies.

 

So the advice is to make a mutual-control between client and server through the use of a heartbeat message.

 

I only have one question:

(A) Server sends a heartbeat message at regular intervals so the client understands that there have been strange not getting the message within a defined lag

(B) Server sends a heartbeat message and the client also sends its own heartbeat message

 

The solution (A) seems more economic, while (B) seems to be the most robust ... what do you think?

[hplus0603]

What you're wanting to solve here is robustness. Both client and server should send heartbeats.