1.9 KiB
Archipelago - Room Server
The room server is meant to handle the direct user workload from Archipelago clients for each room.
Design
There are some things we need to keep in mind for the server design:
Performance
The only limiting factor for hosting should be the servers hardware and not our programming or chosen language. Try to minimize overhead as much as possible for every component.
Scalability
Only run the rooms themselves instead of the whole website, api, management, etc all in one service. This allows using less expensive hardware for the room servers such as virtual servers and similar.
Protocols
The room server implements the client protocol for the management server and the server protocol for the room server(s).
Management (Client)
See the Archipelago - Manager Server project for the protocol information.
Room (Server)
At the current time the following protocols are to be supported:
Official Protocol
The server currently implements the official protocol (documented here on the official repository). This can be implemented in one of two ways:
1. Individual Room Servers
This is the way the official server currently does it: Each room gets its own WebSocket server and the associated overhead. This has some drawbacks:
- The number of rooms is hard limited to 65535 per IPv4 and IPv6 address assigned to the machine.
- Opening many has some not insignificant user-space and kernel-space overhead attached to it.
- Port scanning allows people to see which rooms are running, if any.
For obvious reasons, we do not want to implement this.
2. Single Overall Room Server
We can use the password field to uniquely identify which room a user actually wants to work with. This allows us to remove all the drawbacks in exchange for additional workload required to ensure that we don't stall all rooms.