Photon doesn't call callbacks with opLeaveRoom()
Options
HI.
In Photon v4.0.0.0,
When I call ExitGames::LoadBalancing::Client->opLeaveRoom(),
Photon doesn't call ExitGames::LoadBalancing::Listener::leaveRoomReturn() and the connection has already been disconnected.
Did some Photon's behavior change?
FYI, disconnectReturn() is also not called, because of it, errorCode is 1023 in connectionErrorReturn().
In Photon v4.0.0.0,
When I call ExitGames::LoadBalancing::Client->opLeaveRoom(),
Photon doesn't call ExitGames::LoadBalancing::Listener::leaveRoomReturn() and the connection has already been disconnected.
Did some Photon's behavior change?
FYI, disconnectReturn() is also not called, because of it, errorCode is 1023 in connectionErrorReturn().
0
Comments
-
Hi iwahara.
This actually is a bug in the 4.0.0.0 release.
Thanks for reporting it.
We have just published version 4.0.0.2 in our download section, which addresses this bug and also the performance issue that you have reported last week.0 -
Hi Kaiserludi.
We applied latest version to our app, but this bug still not fixed.
FYI, Our function-call flow is shown below:
ExitGames::LoadBalancing::Client->connect()
↓
ExitGames::LoadBalancing::Client->opCreateRoom() or opJoinRoom()
↓
(user interaction to leave room)
↓
ExitGames::LoadBalancing::Client->opLeaveRoom()
Seems like the connection is disconnected when I call opLeaveRoom(), and connectionErrorReturn is called from Photon. (errorCode is 1023.)
Logs when I call opLeaveRoom() are here. (Log Level ALL)cocos2d: debugLevel[4], message[2015-01-16 12:08:13,768560 DEBUG PeerBase.cpp serializeOperation() line: 388 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,768968 DEBUG EnetPeer.cpp send() line: 741 - cType: 6 payloadSize: 5] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,769287 DEBUG EnetPeer.cpp queueOutgoingReliableCommand() line: 854 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,842084 DEBUG EnetPeer.cpp onReceiveData() line: 591 - length = 24, error = 0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,842395 DEBUG EnetPeer.cpp onReceiveData() line: 633 - peerID=0 flags=0 commandCount=1 sentTime=-2094475857 mChallenge=0xF0B63DE0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,842758 DEBUG EnetPeer.cpp execute() line: 1056 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,842996 DEBUG EnetPeer.cpp queueOutgoingAcknowledgement() line: 878 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,843288 DEBUG EnetPeer.cpp onReceiveData() line: 591 - length = 24, error = 0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,843550 DEBUG EnetPeer.cpp onReceiveData() line: 633 - peerID=0 flags=0 commandCount=1 sentTime=-2094474810 mChallenge=0xF0B63DE0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,843793 DEBUG EnetPeer.cpp execute() line: 1056 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,844012 DEBUG EnetPeer.cpp queueOutgoingAcknowledgement() line: 878 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,844285 DEBUG EnetPeer.cpp onReceiveData() line: 591 - length = 24, error = 0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,844527 DEBUG EnetPeer.cpp onReceiveData() line: 633 - peerID=0 flags=0 commandCount=1 sentTime=-2094471763 mChallenge=0xF0B63DE0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,844910 DEBUG EnetPeer.cpp execute() line: 1056 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,845140 DEBUG EnetPeer.cpp queueOutgoingAcknowledgement() line: 878 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,845486 DEBUG PeerBase.cpp service() line: 195 - dispatch == true] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,845789 DEBUG EnetPeer.cpp dispatchIncomingCommands() line: 380 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,846017 DEBUG EnetPeer.cpp sendOutgoingCommands() line: 141 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,846303 DEBUG EnetPeer.cpp serializeToBuffer() line: 995 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,846666 DEBUG EnetPeer.cpp serializeToBuffer() line: 995 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,846891 DEBUG EnetPeer.cpp queueSentReliableCommand() line: 889 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,847208 DEBUG EnetPeer.cpp sendOutgoingCommands() line: 232 - written/used bytes: 89] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,957861 DEBUG EnetPeer.cpp onReceiveData() line: 591 - length = 52, error = 0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,958166 DEBUG EnetPeer.cpp onReceiveData() line: 633 - peerID=0 flags=0 commandCount=2 sentTime=-2094467420 mChallenge=0xF0B63DE0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,958428 DEBUG EnetPeer.cpp onReceiveData() line: 651 - +++ commandCount: 2] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,958659 DEBUG EnetPeer.cpp execute() line: 1056 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,958879 DEBUG EnetPeer.cpp execute() line: 1090 - CT_ACK] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,959121 DEBUG EnetPeer.cpp removeSentReliableCommand() line: 1216 - removeSentReliableCommand(5, 0)] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,959361 DEBUG PeerBase.cpp updateRoundTripTimeAndVariance() line: 594 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,959575 DEBUG EnetPeer.cpp execute() line: 1056 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,959786 DEBUG EnetPeer.cpp execute() line: 1134 - CT_SENDRELIABLE] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,960003 DEBUG EnetPeer.cpp queueIncomingCommand() line: 901 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,960315 DEBUG EnetPeer.cpp queueOutgoingAcknowledgement() line: 878 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,960651 DEBUG PeerBase.cpp service() line: 195 - dispatch == true] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,960884 DEBUG EnetPeer.cpp dispatchIncomingCommands() line: 380 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,961131 DEBUG PeerBase.cpp deserializeOperation() line: 440 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,961374 DEBUG PeerBase.cpp deserializeOperation() line: 459 - bodyBuff: 8, msgType: 3 (event = 4)] cocos2d: debugLevel[3], message[2015-01-16 12:08:13,961714 INFO Client.cpp onOperationResponse() line: 608 - OperationResponse - operationCode: 254, returnCode: 0] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,962187 DEBUG PhotonPeer.cpp disconnect() line: 91 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,962433 DEBUG EnetPeer.cpp queueOutgoingReliableCommand() line: 854 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,962672 DEBUG EnetPeer.cpp sendOutgoingCommands() line: 141 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,962891 DEBUG EnetPeer.cpp serializeToBuffer() line: 995 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,963111 DEBUG EnetPeer.cpp queueSentReliableCommand() line: 889 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,963351 DEBUG EnetPeer.cpp sendOutgoingCommands() line: 232 - written/used bytes: 24] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,963746 DEBUG EnetPeer.cpp dispatchIncomingCommands() line: 380 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:13,964020 DEBUG EnetPeer.cpp sendOutgoingCommands() line: 141 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,016176 DEBUG EnetPeer.cpp onReceiveData() line: 591 - length = 32, error = 0] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,016489 DEBUG EnetPeer.cpp onReceiveData() line: 633 - peerID=0 flags=0 commandCount=1 sentTime=-2094467342 mChallenge=0xF0B63DE0] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,016753 DEBUG EnetPeer.cpp execute() line: 1056 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,016971 DEBUG EnetPeer.cpp execute() line: 1090 - CT_ACK] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,017240 DEBUG EnetPeer.cpp removeSentReliableCommand() line: 1216 - removeSentReliableCommand(6, 255)] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,017492 DEBUG PeerBase.cpp updateRoundTripTimeAndVariance() line: 594 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,017707 DEBUG EnetPeer.cpp execute() line: 1122 - DISCONNECT COMPLETE] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,018111 DEBUG PeerBase.cpp connect() line: 153 - address: ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,018331 DEBUG PeerBase.cpp reset() line: 136 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,018829 DEBUG PeerBase.cpp service() line: 195 - dispatch == true] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,019192 DEBUG EnetPeer.cpp dispatchIncomingCommands() line: 380 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,019438 DEBUG EnetPeer.cpp sendOutgoingCommands() line: 141 - ] cocos2d: debugLevel[4], message[2015-01-16 12:08:14,079601 DEBUG EnetPeer.cpp onConnect() line: 561 - ]
0 -
Hi iwahara.
I can't reproduce any error 1023 with the latest version and your log also looks like everything does as expected. It also does not contain error code 1023.
Can you reproduce this with one of our demos?
If yes, how?
If it works fine with the demos, then it must be something that your app does differently than our demos. In that case we would need a self contained reproduction case from you to be able to identify what is causing your problem.0 -
Hi.Kaiserludi.
I compared demo and my application, and I found the following difference.
My application:
ExitGames::LoadBalancing::Client->connect(serverAddr, ExitGames::LoadBalancing::ServerType::MASTER_SERVER)
Demo:
ExitGames::LoadBalancing::Client->connect()
My application works fine when I rewrite my code like a demo, but I'm not sure if this change is right.
What's the difference between the two?0 -
Hi iwahara.
Starting with Photon 4 connect() accepts the server type as parameter. One can choose between name server and master server.
Name server should be the choice with Photon Cloud and master server should be the choice with Photon server.
If you don't specify a server type, then the client will use the default value, which is "name server".
So the first of your two code lines interprets serverAddr as a master server address, while the second one connects to the default name server address, which is the Photon public cloud name server.
Please be aware, that the server address that you pass for parameter 1 has to actually run the type of server that you specify for parameter 2, or photon will exhibit undefined behavior.
There are three different types of Photon servers: game servers, master servers and name servers.
The game servers are those servers, which actually host the open game rooms.
As the capacity of a single game server is limited (it depends on the hardware, but on the Photon Cloud a typical game server can host about 2.000 CCU), the clients do not directly connect to a game server, but ask a master server to which game server they should connect to.
The master servers host the lobby and handle load balancing of game servers: If a client wants to join a room, then the master server tells the client, which game server that room is hosted on and if a client wants to create a new game room, then the master server checks the load of the different game servers (used cpu, ram, bandwith, already running game rooms, player counts, etc.) and tells the client, on which game server is should create that room.
Although a single master server can handle quite some game servers and the clients of those game servers, it also has a limited capacity itself. Separate cloud regions use separate master servers, so the worldwide CCU isn't the limiting factor here. However if in a single cloud region the amount of CCU is higher than a single master server can manage, then we have to use multiple master servers for that region.
Therefor starting with Photon 4 clients that connect to the Photon cloud should not connect to a master directly anymore, like they do with Photon 3, but instead they should connect to the Photon name server. This name server will then present a list of master servers, that still have free capacity, to the client to choose from.
Currently the name server feature is only available with Photon Cloud, so with a self Photon Server the clients should continue to directly connect to a master server.
The Client constructor now has a parameter named useDefaultRegion, which default value is true. The value of this parameter is only relevant when the server type is set to ServerType::NAME_SERVER.
In that case, "true" means, that the client will automatically choose the first element from the list of available regions, while "false" means, that instead of choosing the default region, the client lib will rather call the new callback Listener::onAvailableRegions() and pass two vectors to that callback function, one containing the short names of the available regions, the other one containing the address of a master server with free capacity in that region.
Your implementation of that callback should choose one of those regions and pass that choice to Client::selectRegion().
NetworkLogic.cpp from demo_loadbalancing contains an example implementation of this flow, which is the new way of specifying that you want to connect to for example the Photon Japan cloud instead of the default Photon EU cloud.
However even with ExitGames::LoadBalancing::Client->connect(serverAddr, ExitGames::LoadBalancing::ServerType::MASTER_SERVER) it is not intended that the client gets a connection error on leaving a room. This is error comes from another bug, that I have found today after specifically testing this scenario. We have not stumbled upon it it before, because unfortunately this bug does not trigger that error, when one runs a local Photon server on the same machine as the client (the bug is, that the masterserver address only gets saved when connecting via the name server, but not when directly connecting to the master server).
I will try to release a bugfix for this tomorrow.0 -
Hi Kaiserludi.
Thank you for detailed explanations.
OK, I understand that I should call connect() without argument in my app which uses Photon Cloud.0