Page 1 of 1
Room Handling seems Unreliable
Posted: 15 Mar 2012, 13:25
by andrew2110
Hello all,
I'm having some issues with the way the new Smartfox handles rooms. I've created a MMORPG which is divided into a number of maps, each of these maps is it's own Smartfox Room. On entering a new map - a user will check to see if a smartfox room of that name already exists, if it doesn't it will create that room and then join, otherwise it will just join the existing room which ended
The first problem I came across was that _smartfox.getRoomByName(aRoomName) does not seem to give a reliable result as a lot of the time, it will return rooms that no longer exist on the server... This lead to the whole thing becoming confused and lead to multiple rooms being created with the same name as illustrated here:
Not such a problem as I've now taken away room creation from the client and placed it in server code.. However now I'm finding another problem:
The auto-remove mode is set to WHEN_EMPTY and the room is empty, yet the room is not removed. I initially had it so that it was the server who "owned" the room thinking that might be the issue, so I assigned the user to the room hoping this might fix it but it did not.
At the moment, this result is not so bad - but the game is designed to be spread over potentially hundreds of maps and my concern is getting into a situation where when Smartfox sends the client the initial room list, the client is sent thousands of bytes rather than hundreds.
Re: Room Handling seems Unreliable
Posted: 16 Mar 2012, 17:18
by Lapo
Are you using the latest version of SFS2X?
If yes, can you describe the way in which the problem occurs?
thanks
Re: Room Handling seems Unreliable
Posted: 16 Mar 2012, 19:32
by andrew2110
I was using a release candidate 2, and on wednesday updated to the latest version of smartfox 2x and installed it on a separate server. The issue seems to be sporadic. Putting the code to create the rooms on the server side seems to have eased the issue slightly but not solved it as rooms are not being removed when empty.
The servers been up for nearly 20 hours - another screenshot from the admin tool illustrating the issue:
If it helps, heres the code for creating new rooms on the servers side:
Code: Select all
String roomName = aParams.getUtfString("r");
ZoneExtension parent = (ZoneExtension) this.getParentExtension();
CreateRoomSettings roomSettings = new CreateRoomSettings();
CreateRoomSettings.RoomExtensionSettings extSettings = new CreateRoomSettings.RoomExtensionSettings("roomExtension","terrapets.RoomExtension");
roomSettings.setMaxUsers(100);
roomSettings.setMaxVariablesAllowed(100);
roomSettings.setName(roomName);
roomSettings.setAutoRemoveMode(SFSRoomRemoveMode.WHEN_EMPTY);
roomSettings.setExtension(extSettings);
try {
trace("Doing Create Room"+aUser.getName());
this.getApi().createRoom(parent.getParentZone(), roomSettings, aUser);
} catch (SFSCreateRoomException e) {
// TODO Auto-generated catch block
trace("Error: "+e.toString());
}
And I know it probably makes no difference, but we're using the 5000 user license
Re: Room Handling seems Unreliable
Posted: 16 Mar 2012, 20:19
by Lapo
From the screenshot it doesn't appear that the room has a duplicate name, at least from what I can see.
As far as the room not being removed there is one caveat: are you sure that the room was ever joined? If no one joins it then it will stay there "forever" until someone goes there. Finally when the user goes out the Room will be removed.
You can check the logs for join errors.
Re: Room Handling seems Unreliable
Posted: 16 Apr 2012, 09:16
by andrew2110
Sorry to resurrect a dead thread but I'm getting more and more confused by this...
On trying to join a room, the user will first check to see if it exists in their local roomList - if it doesn't exist, it will send a command to the server asking the server to create a room. The servers code for doing this is:
Code: Select all
package terrapets;
import java.util.List;
import terrapets.ZoneExtension;
import com.smartfoxserver.v2.api.CreateRoomSettings;
import com.smartfoxserver.v2.entities.Room;
import com.smartfoxserver.v2.entities.SFSRoomRemoveMode;
import com.smartfoxserver.v2.entities.User;
import com.smartfoxserver.v2.entities.Zone;
import com.smartfoxserver.v2.entities.data.ISFSObject;
import com.smartfoxserver.v2.exceptions.SFSCreateRoomException;
import com.smartfoxserver.v2.extensions.BaseClientRequestHandler;
public class RoomCreateHandler extends BaseClientRequestHandler {
@Override
public void handleClientRequest(User aUser, ISFSObject aParams) {
// Get the client parameters
String roomName = aParams.getUtfString("r");
ZoneExtension parent = (ZoneExtension) this.getParentExtension();
Zone z = parent.getParentZone();
List<Room> rl = z.getRoomList();
for(int i=0;i<rl.size();i++)
{
if(rl.get(i).getName().equals(roomName))
{
return;
}
}
CreateRoomSettings roomSettings = new CreateRoomSettings();
CreateRoomSettings.RoomExtensionSettings extSettings = new CreateRoomSettings.RoomExtensionSettings("roomExtension","terrapets.RoomExtension");
roomSettings.setMaxUsers(100);
roomSettings.setMaxVariablesAllowed(100);
roomSettings.setName(roomName);
roomSettings.setAutoRemoveMode(SFSRoomRemoveMode.NEVER_REMOVE);
roomSettings.setExtension(extSettings);
try {
this.getApi().createRoom(parent.getParentZone(), roomSettings, null);
} catch (SFSCreateRoomException e) {
trace("Error: "+e.toString());
}
}
}
What I want this code to do is:
- Check to see if room already existed
- If it doesn't exist, create a new room, the owner is the server, never remove this room.
However, as you can see from the attached image, multiple occurences of the same room are being created which is breaking the game.
Any ideas on any way I can stop this from happening?
Re: Room Handling seems Unreliable
Posted: 16 Apr 2012, 09:55
by Lapo
The problem is concurrency. Two users are attempting to create a Room with the same name your code could end up generating two rooms with the same name. Suggestion: why not creating Rooms that have a unique ID? For example by adding the creator's id to the name or using an auto-increment index or similar. This way you can avoid synchronization issues.
Re: Room Handling seems Unreliable
Posted: 16 Apr 2012, 10:28
by andrew2110
Thanks for the quick reply Lapo - the problem is - The game is an MMORPG and each room represents a "map". Once on the map is created it never has to be deleted again and users can freely enter and leave that map without having to call the create room function again.
Because of this - we can't create rooms with unique names - as on the client side we wouldn't know which room represented which map. It was my understanding that Smartfox 2X should just throw an error when it tries to create a room with the same name as one that already existed? Am not sure why exactly this is not happening?
If I've understood your reply correctly then it's just that two users have decided to create a room at exactly the same time and a race condition has occurred on Server side leading to two identical rooms being created?
It would be ok if I could manually delete the multiple instances of identical rooms in the admin but it just shows me the confirmation screen and then does nothing..
Re: Room Handling seems Unreliable
Posted: 16 Apr 2012, 12:29
by Lapo
If you have several locations mapped to several Rooms that are meant to exist "forever" then I would highly suggest to start all those Rooms at startup maybe splitting them into Groups for best organization.
The problem with your use case is that you are creating Rooms on demand that have a fixed name and that can be contended by a ton of users at the same time, when requesting to join a Room. You could force some sort of synchronization but there are ways around it which scale better. (the one suggested above)
If I've understood your reply correctly then it's just that two users have decided to create a room at exactly the same time and a race condition has occurred on Server side leading to two identical rooms being created?
Yes it is correct but we use a less coarse level of synchronization than that to promote scalability. You can alway use stricter synchronization if you wish and if the use case dictates it.