OnRoomJoin\OnRoomAdded order

[Lapo]

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'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.
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));

This generates very high concurrency since the test runs on the localhost where latency is around 0.1ms

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

[Lapo]

One more thing. In the mini log dump you posted it is shown a number of Rooms apparently with the same name.
I suspect this is due to the way the provided RoomSettings object is passed to the QuickJoin request. The name of the the new Room that gets created if the match expression returns nothing should be randomized and unique. Check our example provided in the my previous post.