Hi
Recently we enabled HRC feature in our production environment in order to overcome some momentary disconnections.
Let's say we send messages (TCP) 11 12 13 14 to our clients and one of the clients encounters an issue just before sending a message no. 13.
I observe that after reconnecting the client receives message no. 14, but not 13. I assume you save all the messages in a queue and send all the missing messages after reconnecting success.
We mostly observe it on iPhone clients version 1.7.10.
What is the expected behavior?
HRC feature
-
- Posts: 25
- Joined: 28 Jun 2020, 08:54
Re: HRC feature
Hi,
when the user disconnects, the server accumulates the outgoing messages into the relative queue until the client comes back.
It is possible that a message gets lost if it was sent right before the player got disconnected, though its' not expected to happen very often.
when the user disconnects, the server accumulates the outgoing messages into the relative queue until the client comes back.
It is possible that a message gets lost if it was sent right before the player got disconnected, though its' not expected to happen very often.
-
- Posts: 25
- Joined: 28 Jun 2020, 08:54
Re: HRC feature
But we use a TCP connection, in that case, you should enqueue the failed message and resend it when it reconnects, right?
We have a stage in our game that every message must be received, if we don't receive all the messages in the exact order we get stuck.
We can develop a mechanism of asking for a specific message when we expect message no. 4 but received 5 (like TCP), but we expected your feature to work perfectly.
What do you suggest?
We have a stage in our game that every message must be received, if we don't receive all the messages in the exact order we get stuck.
We can develop a mechanism of asking for a specific message when we expect message no. 4 but received 5 (like TCP), but we expected your feature to work perfectly.
What do you suggest?
Re: HRC feature
rafaelb149 wrote:But we use a TCP connection, in that case, you should enqueue the failed message and resend it when it reconnects, right?
Unfortunately no. Once a message is sent out we have no knowledge of it failing to arrive, if a disconnection happens meanwhile. There doesn't exist a mechanism as that.
The "guaranteed delivery" feature of TCP works until a connection exists. If a packet is sent out and the client disconnects before the packet is received, the packet is lost in hyperspace and there is no way of knowing about it, because the channel of communication is down.
We have a stage in our game that every message must be received, if we don't receive all the messages in the exact order we get stuck.
We can develop a mechanism of asking for a specific message when we expect message no. 4 but received 5 (like TCP), but we expected your feature to work perfectly.
What do you suggest?
Maybe you could send the current state of the game back to clients that get reconnected after a disconnection?
Of course this is possible if the game state itself is not too huge.
Cheers
Who is online
Users browsing this forum: No registered users and 56 guests