[Draft] Network scaling

[sepalani]

Here are some thoughts regarding how we can scale up/down the server depending on our needs.

Ideally, we should aim toward a flexible/scalable approach for modest and robust targets. For instance, an old Windows XP vs a modern server. We should be able to redirect the traffic load across threads, processes, external servers... One task might consider to only process the accept'd socket then dispatch it or handle the whole connection.

Socket

Blocking I/O

• Will release Python GIL when blocking.
• (...) TODO

Non-blocking I/O

• Will release Python GIL when non-blocking (might introduce context switching overheads).
• (...) TODO

SO_REUSEPORT option

• The SO_REUSEPORT socket option
• Avoiding unintended connection failures with SO_REUSEPORT
• SO_REUSEADDR vs SO_REUSEPORT

Select

• Multiple threads mustn't monitor the same socket.
• (...) TODO

Poll

• Multiple threads mustn't monitor the same socket.
• (...) TODO

Load balancing

• Select vs multi-threading

Threads

• Not much benefit unless I/O bound, ex: socket read/write/select/poll.
• The GIL and its effects on Python multithreading

Processes

• Costly, requires some kind of IPC.

External servers

• Costly, requires some kind of IPC.
• Will most likely concern FMP servers (i.e. in-game server which are holding city gates).

Synchronization

"Central server" refers to an info server centralizing data accessible/shared by multiple servers. Player's name/status/equipment/Capcom ID are considered as such.
At some point, we should provide a way to register external servers.

Autonomous approach

• A server is only responsible for its players/connections.
• The server might ask a "central" server for external data (player search).
• A "central" server might ask the server for some of its internal data (current player state, server capacity, etc.).

Synchronizing approach

• Require a locking mechanism to prevent data alteration.
• External servers will always ask a "central" server when accessing shared data.