SFS2X Docs / Overview / zones-room-architecture
» Zones and Rooms architecture
A Zone represents one application (a chat, a game, etc) running in SmartFoxServer. The server can run many Zones simultaneously, each one independent from the others and with its own custom server side logic. Users connected to a Zone can be grouped into Rooms.
A Room is a common concept in the realm of socket servers that means "a collection of users". In SmartFoxServer, a Room is a way for users to interact with each other and share data. As a very basic example, consider a chat message: if a user is in a Room, then that user can send a public chat message, which is then broadcast to all users in that Room.
Users can also be inside multiple Rooms at the same time.
Rooms can be defined statically in the Zone configuration (Rooms will be created when the server is started) or they can be created dynamically through specific client or server side calls.
» Room Groups
Room Groups allow to organize Rooms into logical groups, separated from each other. Users will be able to subscribe for events happening in the Groups they are interested in, ignoring all the others.
A major advantage of this approach is that the initial room list sent by the server will be smaller, and the number of events fired to each client is highly reduced, especially in case of high traffic applications.
An example will clarify the concept:
An user could initially subscribe to the Lobby group and receive Room updates (such as newly created or removed Rooms, user count changes and Room Variables updates — you will learn what Room Variables are later in this documentation) only for the Rooms under that Group.
If the user is interested in playing games he can subscribe to one of the other game Groups, see which games are available and join them. Users can also unsubscribe any Group at any time. The user could even avoid to subscribe to any Group at all and still be able to join any Room in the Zone, although he won't receive any updates from Rooms that are not joined.
This approach, in conjunction with the fine-grained level of Zone and Room configuration, allows the application designer to create highly sophisticated systems with multiple lobbies, games, personal rooms, private areas, etc. This feature also provide a more rational and organized way to manage thousands of Rooms in the Zone while keeping the amount of client updates to the bare minimum.
The following list describes a few different possible scenarios.
- User joins the Zone without subscribing to any Room Group: in this case the user will receive an empty room list and won't be updated by the server about any Room event. This is a good setup when you want to let the user interact with your server-side application logic without having to receive unwanted Room updates. A typical use case is the user registration form, consulting a user-search functionality or other user-profile related activities where the interaction with other clients is not required.
- User joins the Zone and subscribes an initial Room Group: this is probably the most common use case. The Room list received by the client will contain only the Rooms in the selected Group and will filter out all the others. The client will be updated about newly created or removed rooms by default. The developer will also be able to configure other events such as the user count update, Room Variables update, etc.
- User joins the Zone and subscribes multiple Room Groups: subscribing multiple Groups allow for a more sophisticated Room filtering. The player will be able to obtain a custom Room list composed by the Rooms in the selected Groups. Typically the client will join a Lobby group, maybe a Chat group with a specific theme and a Game group where he can look for games to play.
Finally Groups can be created at runtime and subscribed/unsubscribed dynamically.
More in-depth information on Rooms can be found in the Room architecture document.