PUN Reconnect
Options
Hello,
I'm trying to implement user rejoin after random disconnect and I'm not sure how to fix an issue.
The issue: I don't know how many messages (RPC calls) the disconnected user has received and what i have to resend.
A fix would be to basically double the message number(for every message sent call a Message Received RPC), on user reconnect resend the messages with no "received" RPC.
This solution sounds a bit extreme to me. Is there any other way to do this?
Thanks for any replies.
I'm trying to implement user rejoin after random disconnect and I'm not sure how to fix an issue.
The issue: I don't know how many messages (RPC calls) the disconnected user has received and what i have to resend.
A fix would be to basically double the message number(for every message sent call a Message Received RPC), on user reconnect resend the messages with no "received" RPC.
This solution sounds a bit extreme to me. Is there any other way to do this?
Thanks for any replies.
0
Best Answer
-
Hi @Bonzy,Your solution looks good yes.
Solved it by adding an ID for each message sent, the reconnecting user sends last received ID.Is this the way to goIt depends on your game.is there another easier way to know that a message hasn't been received because of disconnect?No sorry. PUN and Photon Realtime in general has some reliability layer that makes use of ACKs to ensure messages get sent/resent. But in some edge cases like the one you are mentioning this does not happen.
PUN RPC are events under the hood. I'm more familiar with RaiseEvent so I will tell you about what I tried to do to solve this:
- cache event locally before sending it. use it to resend event after timeout or after recovering from unexpected disconnect.
- broadcast (send events to All including sender). receiving my own event is considered an ACK from server as RaiseEvent operation does not have operation response in case of success => remove local copy.
- cache important events inside the room.
- clean up cached events inside the room once it has been successfully transmitted. removing the event from cache is considered an ACK from target actor(s).1
Answers
-
Solved it by adding an ID for each message sent, the reconnecting user sends last received ID.
Is this the way to go or is there another easier way to know that a message hasn't been received because of disconnect?
0 -
Hi @Bonzy,Your solution looks good yes.
Solved it by adding an ID for each message sent, the reconnecting user sends last received ID.Is this the way to goIt depends on your game.is there another easier way to know that a message hasn't been received because of disconnect?No sorry. PUN and Photon Realtime in general has some reliability layer that makes use of ACKs to ensure messages get sent/resent. But in some edge cases like the one you are mentioning this does not happen.
PUN RPC are events under the hood. I'm more familiar with RaiseEvent so I will tell you about what I tried to do to solve this:
- cache event locally before sending it. use it to resend event after timeout or after recovering from unexpected disconnect.
- broadcast (send events to All including sender). receiving my own event is considered an ACK from server as RaiseEvent operation does not have operation response in case of success => remove local copy.
- cache important events inside the room.
- clean up cached events inside the room once it has been successfully transmitted. removing the event from cache is considered an ACK from target actor(s).1