From CatchChallenger wiki
Why not use all the cpu?
- Use all the cpu mean have big lock on the general data. It slow down all the thread operations, use system time, have dead lock, ...
- That's structure allow good data locality, then good usage of the cpu cache.
- All task have one thread, that's allow task isolation, and prevent performance lost on preampt (disk access, wait db, ...)
- The heavy action is async by epoll, async database
- Buffer and epoll to prevent blocking socket access
- broad cast thread: all broad cast object interconnected, complexity: O(n), where n is all player, limited by ddos and cpu usage mutualised to forge onetime the packet
- map management thread: local map management object interconnected, complexity: O(n) for local player, but in normal case O(n^2) for all players see the other player, where n is local player
- see Virtual machine on GPU
All need be statically dispatched with modulo. All block is async.
- Parse network packet: IPv4/IPv6, UDP/TCP, Split: source IP, to optimize IP -> (File descriptor) player map id + player pointer
- Local player: forward to last know map, check the local player variable, control message per second. Sync map move, to have sync monster collision event. Split: player map, to optimize map collision (player object will always be in missed cache)
- Multicast map player: compose other player move, async because it can consume 99% of the CPU into last profile I do, via bit vector if possible to not have infinite buffer due to too slow thread group
- Output network, manage all the output related: packet segmentation, ...