Hi Team,
I've been reading through this documentation: https://docs2x.smartfoxserver.com/Devel ... chitecture based on a thread in the forum about how rooms should be organised into groups to reduce traffic (the userCount update thread).
From the documentation though, I can't figure out the mechanism behind this. How do room groups fit into this and reduce the traffic sent to the client?
In our game there will be upwards of 500 rooms available at any one time, on busy days over 1,000. I do group these, but only for my own ability to filter them in the admin tool. 99% of users don't care about any other room than the 2 (or 3) that they are currently in and the server controls which rooms they are in at any given time. Given this, if I could remove all update traffic for all other rooms that would be great.
Thanks.
Room Update Events and Groups
Re: Room Update Events and Groups
Hi,
A standard Zone has one group called "default" where all Rooms are created and all clients are subscribed to it.
So if you have thousands of Game Rooms every User will download that huge list of Rooms at login time and will also be auto-subscribed to all notifications about Rooms being added/removed and changes to the user count.
If you could split these Rooms in several Groups and subscribe clients only to what they are interested in, you'd save some resources in terms of server work and traffic.
Yes, ultimately it depends on the application design.
If you have different types of games, e.g. poker, black-jack, craps etc... you can subscribe users only to the game they're interested.
It is true that Players are interested in the few Rooms they have joined, but it's also true that as soon as they leave and want to go somewhere else they already have an updated Room list available, because the system was keeping it updated behind the scenes via the various Room events. The alternative would be to re-obtain the whole list, which is heavier than keeping it updated with smaller events.
There's also a more radical approach that you can take: do not subscribe to any Room Group at all. This way clients will not receive any room list or events and implement the match-making/join system on the server side, via Extensions.
On the server side you tools such as:
SFSApi.findRooms()
SFSApi.quickJoinOrCreateRoom()
SFSGameAPI.quickJoinGame()
combine these with the Invitation system (also provided by the Game API) and you can build pretty much whatever you want in terms of match-making.
In other words you can bypass the standard room list/room events system and create your own based on the specifics of your game(s)
Hope it helps
From the documentation though, I can't figure out the mechanism behind this. How do room groups fit into this and reduce the traffic sent to the client?
A standard Zone has one group called "default" where all Rooms are created and all clients are subscribed to it.
So if you have thousands of Game Rooms every User will download that huge list of Rooms at login time and will also be auto-subscribed to all notifications about Rooms being added/removed and changes to the user count.
If you could split these Rooms in several Groups and subscribe clients only to what they are interested in, you'd save some resources in terms of server work and traffic.
In our game there will be upwards of 500 rooms available at any one time, on busy days over 1,000. I do group these, but only for my own ability to filter them in the admin tool. 99% of users don't care about any other room than the 2 (or 3) that they are currently in and the server controls which rooms they are in at any given time. Given this, if I could remove all update traffic for all other rooms that would be great.
Yes, ultimately it depends on the application design.
If you have different types of games, e.g. poker, black-jack, craps etc... you can subscribe users only to the game they're interested.
It is true that Players are interested in the few Rooms they have joined, but it's also true that as soon as they leave and want to go somewhere else they already have an updated Room list available, because the system was keeping it updated behind the scenes via the various Room events. The alternative would be to re-obtain the whole list, which is heavier than keeping it updated with smaller events.
There's also a more radical approach that you can take: do not subscribe to any Room Group at all. This way clients will not receive any room list or events and implement the match-making/join system on the server side, via Extensions.
On the server side you tools such as:
SFSApi.findRooms()
SFSApi.quickJoinOrCreateRoom()
SFSGameAPI.quickJoinGame()
combine these with the Invitation system (also provided by the Game API) and you can build pretty much whatever you want in terms of match-making.
In other words you can bypass the standard room list/room events system and create your own based on the specifics of your game(s)
Hope it helps
Re: Room Update Events and Groups
There's also a more radical approach that you can take: do not subscribe to any Room Group at all.
Well... based on your response I do believe I've inadvertently gone down this route anyway!
This does explain why a few things don't work as I thought they did.
Thanks for explaining it for me
