Mrm83 wrote:Which version of Unity are you using? Newer than 2018.2?

2017.2 because it is the last version, that should be compatible with the Windows XP

Unless they change something significantly, i will save you some time and tell you, that it will not work.
We had same issue year or two before and i think it is related to the fact, that android (until 5) does not have TLS 1.2 enabled by default.

When i wrote the first post, i was not sure, what is the cause of the issue, now i know. At least you can see, for how i am fighting this bug. So, problem occurs, when i read the variables in SFSEvent.ROOM_ADD, as it is in the code snippet i sent you. That is it. So, from the client (my unity applic...

Are you running the code in Unity? Or is it a C# standalone project? Unity Do you change the setting of the SmartFox.ThreadSafeMode property in your code? It is set to true: // Set ThreadSafeMode explicitly, or Windows Store builds will get a wrong default value (false) Sfs.ThreadSafeMode = true;

No, sequential request-response create & join room

This is simplified version. Sfs.AddEventListener(SFSEvent.ROOM_JOIN, (evt) => { Room room = (Room)evt.Params["room"]; var gameDataVar = room.GetVariable("gameData"); if (gameDataVar == null) { Debug.LogError("Room " + room.Id + " has no gameData"); return; } /...

I am reading room variables on SFSEvent.ROOM_ADD event. I have a list of rooms, that i am showing to the user - like how many players are in the room, etc. Every time SFSEvent.ROOM_ADD event occurs, i am creating a new instance of it. Problem is, that sometimes, when i am creating the room, i get Ro...

...
if (user.getSomeBoolean())
{
throw new Exception()
}

user.SetSomeBoolean(true);
...

is not thread safe solution. Is it solution you use in joinRoom api or not?

Lapo wrote:To reiterate: each join transaction (for the same User) has to be completed before another one can be started.
Other than that joining Rooms is perfectly thread safe and concurrent.

I am asking you to PROVE your statement by showing the code snippet of joinRoom implementation.

SfS Reality: In reality, there are several parts of the system, that cannot handle concurency correctly Why not? Not handling concurrency correctly means corruption of data. This is not the case. You're simply warned by an error. Why don't you use the solution I provided? Could you share a code sni...

Lapo 2010: In general I don't like the idea. Multithreading offers scalability. Forcing the game logic to run sequentially would pose possible risks of inability to scale. Honestly with today's Java5/6 new concurrent collections and tools handling concurrency is not much of a pain, most of the hard ...

What is the difference between solution you proposed and making joinRoom synchronized on your end?

REQUIREMENTS 1. There are two players per room, both players have to agree to play a game to initiate a game (and create a room) 2. Any playes may play any number of game simultaneously Simple scenario 1. Player A opens a game request with multiple other players (player B, Player C, ... , Player X) ...

Makes sence, but not in our case, because that is not how our client does it.

We just cannot do that on client side, because the client is not the only iniciator of the room join.

Which calls are asynchronous, handleClientRequest?

Multiple client requests leads to joining the room, so how would you implement the waiting you have suggested?