Re: OnRoomJoin\OnRoomAdded order
Posted: 22 Dec 2025, 16:02
We've tested with C# API 1.8.5 and both SFS2X 2.19.0 and SFS2X 2.20.5 and haven't found any client side errors or indications that anything breaks apart.SFS2x version is 2.19.0
Client api version 1.8.5
The issue is incorrect order of onRoomJoin and onRoomAdded events. This does not happen consistently, in some cases onRoomAdded is received after onRoomJoin.
We have set up an app that generates 60 clients (60x instances of the SmartFox class), connects and login all of them and then waits for a signal from the Extension. When the signal is triggered all 60 clients send the following request:
Code: Select all
var expr = new MatchExpression(RoomProperties.IS_GAME, BoolMatch.EQUALS, true).
And(RoomProperties.HAS_FREE_PLAYER_SLOTS, BoolMatch.EQUALS, true);
RoomSettings crs = new RoomSettings("Room__" + sfs.MySelf.Id + "_" + rng.Next(10_000));
crs.MaxUsers = (10);
crs.IsGame = true;
crs.GroupId = "poker";
sfs.Send(new QuickJoinOrCreateRoomRequest(expr, ["poker"], crs));It is possible that in some situations the RoomJoin event of a User precedes the AddRoom, because many of these concurrent requests happen in the same millisecond, however the API state is preserved.
Example:
User A is creating a Room (and then join it)
User B is searching for a free Room to play
Threads can be interleaved in a way where User B joins the new Room (created by User A) before User A joins it. In this case User B will likely get the RoomJoin event slightly before the RoomAdd event.
This is what happens on the client side for User B:
- the RoomJoin event arrives
- client API acknowledges the new Room (say, id=10) and adds it to the local list, then triggers the event
- the RoomAdd event arrives
- client API updates the local Room list again (room id is still == 10), then triggers the event
The local state is still preserved.
It would still be possible to make the whole operation atomic but you'd have to synchronize the whole operation on the server side which means creating a lovely bottleneck on that request and thus killing your scalability by a factor equal to the number of cores/threads available.
We tend to avoid that, where possible: i.e. in places where the correct state can be preserved.
To make the QuickJoin process fully sequential, if you absolutely need it, just move the QuickJoin call on the server side (via Extension) and then make it single threaded via a global lock or synchronized block. Just be aware of the scalability penalty that comes with it.
Cheers