PUN+ RPC guaranteed?
Options
Hi again, David here.
I have a new problem. Let's go.
Actually, we are testing android and iphone versions. And I'm experiencing some issues I've never suffered on the PC version.
As the tittle implies, the problem seems to be with the reliability of the RPCs. I've readed in some post, that RPCs are guaranteed to be received once sent. However, I'm having some troubles with this. Pearhaps is a bug on my code... But as said, I've never experienced it while testing on PCs.
We are talking here about PUN+ on android (unity 4.2). Now the problem. We have a turn-based game. When one player does an action, the game shows the action in his screen and then, send a RPC to the other player. Once done this, the first player game change the turn to prevent the player taking any action until the oponent has finished his/her turn. On the other side, once a player RECEIVE an acion, execute it on his/her own game (screen), changes the turn itself, for being able to do an action.
I.E.,
player 1 turn -> makes an action -> reflect that action on his own screen -> change own turn variable -> send RPC
player 2 -> receives RPC -> display action on his screen -> change own turn variable for being able to do an action itself.
Since I've started to test on android/iphone, I've found situations where both turns were wrong, i.e player 1 showed player 2's turn, and player 2 showing player 1's turn (ending with no of both being able of doing any action, obviously).
I can try a work around, simply forcing any action as a RPC. I.E., player 1 execute an action, send a RPC to ALL, and showing the action/changing turn ONLY when receiving the RPC. But since I've readed that RPCs are guaranteed to be received (even if the sender device loose the internet connection briefly?) I'd like to know if this behaviour is the expected one or a bug (on my side or on PUN side).
Thanks again for your support,
--- David ---
P.S. I've not forgotten about the simulator library, just emailed you some days ago.
I have a new problem. Let's go.
Actually, we are testing android and iphone versions. And I'm experiencing some issues I've never suffered on the PC version.
As the tittle implies, the problem seems to be with the reliability of the RPCs. I've readed in some post, that RPCs are guaranteed to be received once sent. However, I'm having some troubles with this. Pearhaps is a bug on my code... But as said, I've never experienced it while testing on PCs.
We are talking here about PUN+ on android (unity 4.2). Now the problem. We have a turn-based game. When one player does an action, the game shows the action in his screen and then, send a RPC to the other player. Once done this, the first player game change the turn to prevent the player taking any action until the oponent has finished his/her turn. On the other side, once a player RECEIVE an acion, execute it on his/her own game (screen), changes the turn itself, for being able to do an action.
I.E.,
player 1 turn -> makes an action -> reflect that action on his own screen -> change own turn variable -> send RPC
player 2 -> receives RPC -> display action on his screen -> change own turn variable for being able to do an action itself.
Since I've started to test on android/iphone, I've found situations where both turns were wrong, i.e player 1 showed player 2's turn, and player 2 showing player 1's turn (ending with no of both being able of doing any action, obviously).
I can try a work around, simply forcing any action as a RPC. I.E., player 1 execute an action, send a RPC to ALL, and showing the action/changing turn ONLY when receiving the RPC. But since I've readed that RPCs are guaranteed to be received (even if the sender device loose the internet connection briefly?) I'd like to know if this behaviour is the expected one or a bug (on my side or on PUN side).
Thanks again for your support,
--- David ---
P.S. I've not forgotten about the simulator library, just emailed you some days ago.
0
Comments
-
The RPCs themselves are guaranteed to reach everyone who is online while you are and in the same room. They can't guarantee that the receiver has the same GameObject ready to execute RPCs.
This means basically: Depending on your logic, you might fire a RPC too late or early for others to execute it. In worst case, the GO instance that resembles the same GO but on another client isn't available. I think there is a log entry for this, when RPCs don't find a target.
I am pretty certain it's a logical bug instead of a proper missing RPC but I know first hand, that it might look very much the same.
Please verify you don't have suspicious log entries when this happens.
You could add more logging at will to OnEvent() in PUN to log RPCs and if they got through properly. I think you won't find missing ones.0 -
Umm... Ok, I can try to look deeper on logs.
Anyway, due to the nature of the UDP protocol (used by PUn by default and recommended by you, if memory serves me well), I suppose that it's not possible to know, for sure, if one concrete RPC has reached one concrete client... I.E., I suppose you should maintain a queue of RPC sent and received by any client to any other one and compare them before sending a new one (of course, I could be wrong here).
In a situation where, for example, one device is on WIFI coverage, but not good coverage, your device could switch connections between 3G and WIFI automatically and repeatedly. The time to switch could not be enough to detect a "OnDisconnectedFromPhoton()" (what I'm trapping), but enough to have a RPC lost...
Could this scenario happen?
In such case... Is there anyway to detect such loss?
Thanks again for all, mate.
BTW, in this case the logic on my side is pretty simple: Send a "click" before excuting it locally. The result was executing it locally, but receiver not detecting it.
--- David ---0 -
It's possible to access the low level repeat counter but it's not exposed in PUN:
PhotonNetwork.networkingPeer.ResentReliableCommands
It's a count of repeats.
In general: Our reliable UDP protocol should handle lost UDP packages. It will simply repeat if it didn't get an ACK. Switching networks either works or breaks the connection completely, as missing ACKs cause a disconnect after a timeout.0
