Room design pattern

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

dinhnq
Posts: 5
Joined: 30 Nov 2017, 23:33

Room design pattern

Postby dinhnq » 01 Dec 2017, 00:56

Hi everyone,

I got a problem when trying to design the play mode with some clan/guild features (Clans in Clash of Clans game could be a reference) such as the Chat system. Currently, I am using the Game Room mechanism with its properties and its variables to manage Clans and share their data to clan members. I wonder if there is a better way to apply in this scenario. Could you help me, please?

There are 2 ways I figure out so far:
    - Members on different servers: Pros - don't care CCU buffer, Cons - code complication to manage multithreads, non-blocking I/O, and to control data transmitting through the "send topic" mechanism of Hazelcast API
    - Members on the same server: Pros - simple code, Cons - take care of CCU buffer, for example, server A (max 2000 CCU) and a clan has 10 members. As a result, the total of rooms/clans on the A server can't exceed 200 (I don't mention to rooms with another purpose). In other words, I can't add more users from another clans into this server if there is already having a total of 200 logged-in users from 200 clans. I cannot do that though the current CCU is 200 because if all members of such 200 rooms are online simultaneously, it would be 2000 CCU !
User avatar
Lapo
Site Admin
Posts: 19933
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Room design pattern

Postby Lapo » 01 Dec 2017, 08:50

Hi,
I think the multi-server approach is what you need here, because of the "locked" allocation of users when a clan (or Room is created)
In other words you need to be able to distribute these Clan's Rooms on a number of server based on what is already allocated.
I can't see many other ways around it.

You said:
- Members on different servers: Pros - don't care CCU buffer, Cons - code complication to manage multithreads, non-blocking I/O, and to control data transmitting through the "send topic" mechanism of Hazelcast API

I am not sure why you would have to deal with non-blocking I/O or multithreading?
I mean, even if you add Hazelcast in the mix all those low-level details are handled for you. Granted, the multithreading is something you will have to work with, but that's true also with SmartFoxServer and in general it won't get in you way that much. In fact, typically it won't at all.

Hope it helps
Lapo
--
gotoAndPlay()
...addicted to flash games
dinhnq
Posts: 5
Joined: 30 Nov 2017, 23:33

Re: Room design pattern

Postby dinhnq » 01 Dec 2017, 09:29

Hi Lapo,

The clan/room has the Battle feature and members will be updated with Victory Points each time they win or lose. The total of clan Victory Points is contributed by members' Victory Points. It would be described in the following flow each time of one battle win or lose:
    - Step 1: the client requests to the server for updating VP of that member and that clan
    - Step 2: update to Database
    - Step 3: use Hazelcast to broadcast the relevant "topic" to servers to update Room Vars/Properties. Assumption: clan members are on different servers and many same rooms must be created

As you can see, we use the non-blocking mechanism because the 2nd step above can take long time and thus the thread must be released soon.

I'm worried if there is too much messages will be broadcasted when we increase the number of servers. Could you please give me some advices? Thank you very much in advance.

One more thing, it's weird to see many identical rooms created on many servers. In my mind, if a group of users plays in a room, they really have to be on the same server.
User avatar
Lapo
Site Admin
Posts: 19933
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Room design pattern

Postby Lapo » 01 Dec 2017, 16:49

dinhnq wrote:Hi Lapo,

The clan/room has the Battle feature and members will be updated with Victory Points each time they win or lose. The total of clan Victory Points is contributed by members' Victory Points. It would be described in the following flow each time of one battle win or lose:
    - Step 1: the client requests to the server for updating VP of that member and that clan
    - Step 2: update to Database
    - Step 3: use Hazelcast to broadcast the relevant "topic" to servers to update Room Vars/Properties. Assumption: clan members are on different servers and many same rooms must be created

As you can see, we use the non-blocking mechanism because the 2nd step above can take long time and thus the thread must be released soon.

Step 2 is the database update. How do you update a database non-blocking or asynch? Do you use "fibers" or stuff like that?
Typically we haven't seen any issues with blocking database calls using thread pools.
SFS2X runs auto-load balancing thread pools so it can grow and shrink them on demand, for instance. This is usually enough even for very high loads. The crucial point is to make sure you have a good, low-latency connection to the database. That alone will save you a lot of scalability headaches.

I'm worried if there is too much messages will be broadcasted when we increase the number of servers. Could you please give me some advices? Thank you very much in advance.

If servers can talk to each other in the same local network I don't think you'll have any issues. A local 10Gbit connection can handle gazillions of small messages per second :)

One more thing, it's weird to see many identical rooms created on many servers. In my mind, if a group of users plays in a room, they really have to be on the same server.

I am not sure what you mean by this?

Thanks
Lapo

--

gotoAndPlay()

...addicted to flash games
dinhnq
Posts: 5
Joined: 30 Nov 2017, 23:33

Re: Room design pattern

Postby dinhnq » 02 Dec 2017, 05:09

Once again, thank you very much Lapo :)

I am designing the Cloud Server architecture like this:
    - DataCenter A: SmartFox Server 1 & 2 + Database NoSQL Server 1 (Cassandra) + Database NoSQL Server 2 (Cassandra)
    - DataCenter B: SmartFox Server 3 & 4
If servers can talk to each other in the same local network I don't think you'll have any issues. A local 10Gbit connection can handle gazillions of small messages per second :)

As you can see, SF 3 & 4 are not in the same local network with SF 1 & 2
- I think the multi-server approach is what you need here, because of the "locked" allocation of users when a clan (or Room is created)
In other words you need to be able to distribute these Clan's Rooms on a number of server based on what is already allocated.
- One more thing, it's weird to see many identical rooms created on many servers. In my mind, if a group of users plays in a room, they really have to be on the same server.
- I am not sure what you mean by this?

Well, I'm standing in the intersection of choosing one of the solutions (Assumption: 10 members per room; Max 2000 CCU per sf server):
    - Oriented room distribution (multi server approach you mentioned): Server A is now having 20 users of 20 rooms. Solution: if a new user or a user of the 21st room tries to log into the server A, the system will redirect him to the Server B
    - Oriented user distribution: Server A is now having 20 users of 20 rooms. Solution: a new user or a user of the 21st room can log into the server A. If the server A reaches 2000 CCU and one member, who is in one of the 20 rooms, tries to access the server A, the system will redirect him to the Server B and will create the identical room ("room X") on the Server B. From that time, "room X" on the server A and "room X" on the server B will talk to each other through Hazelcast

I prefer the first method because of its simplicity. However, it would be more $ to have more Cloud servers and more SmartFox licenses :(

Lapo, your opinion will be valuable to help me making the final decision. :D
User avatar
Lapo
Site Admin
Posts: 19933
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Room design pattern

Postby Lapo » 02 Dec 2017, 15:09

I am not sure I follow. Both alternatives start with the same statement:
Server A is now having 20 users of 20 rooms


If by "Room distribution" you mean that users from the same Room could be connected on different servers, I would not recommend it as it is a major source for all sorts of scalability issues. It is much less painful to keep users that need to frequently interact together on the same machine, local to one another.

Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 14 guests