send event confirm logic


I have a turn based game with only two players.
In current implementation I have a problem. After connection is established, players start to send events each other.
Player 1 sends event to player 2 and waits for response. Player 2 sends event to 1 and waits for response. Simple.
But, when suddenly phone call comes to player 1, game stops, after phone call it resumes, gets network timeout, reconnects.
And some event data is lost. So game enters to state when two players waiting each other...
I'm thinking how to resolve it. First solution is: what about send message to player 2, and wait for ACK. This solves half of issue. Why half? Send message->no ACK, then resend it, fine. But send ACK->and how we know that ACK was received?
I don't want to send ACK for ACK, ... :).
Second solution is: add id number to message, and if message id=123 is not delivered, then id>=124 are ignored. But that requires many code changes in my app, so I want to know first if there is an easier solution.
I need reliable send with confirm that message is delivered to another player. I don't care about speed in turn based game. But if one message is lost and I cannot check if it is lost that's unacceptable.

Does Photon Realtime SDK contain a feature to confirm if event was really sent to another player? Like: SendEvent() and wait for callback SendResult(). I need something that will return me true after message was delivered to another player, not after it was put to send buffer and nobody knows when it will be delivered.


  • Hi @Dmitry_Stepanushkin,

    Thank you for choosing Photon!

    Please start by reading this discussion to look for ideas.
  • edited January 2018
    Thank You! Will look if I can find something useful in my case inside discussion You posted.

    Currently I think about logic like this:
    Player1 sends a message to Player2. Player2 sends only one ACK for each message received from Player1.
    Player1 will wait for data or for ACK from Player2 in this state. Means not send own message2 if message1 ACK is not received. If and only if ACK received Player1 knows 100%, that message is delivered.
    However if something bad happens, Player1 waits for short time(that's just ACK, must be received very soon, or it's a problem), and if no ACK received, sends same message again and again until ACK received.
    ACK=continue, no ACK=retry, then give up.
    Now use the same logic for Player2 as Player1 and I think it's solved.
Sign In or Register to comment.