Server architecture

From CatchChallenger wiki
Jump to: navigation, search

Threads

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, ...)

General organisation

  • 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

GPU mode

CatchChallengerGPU.png

Btree2.png

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, ...