A Comparative Study on Player State Synchronization Topologies: Peer-to-Peer Pub/Sub vs. Master-Slave gRPC Streaming in Multi-Server Game Networks
(ID: Studi Komparatif Topologi Sinkronisasi State Pemain: Pub/Sub Peer-to-Peer dan gRPC Streaming Master-Slave pada Jaringan Game Multi-Server)
Author: [Your Name], [NIM] · Bina Nusantara University · Supervisors: Douglas Rakasiwi Nugroho; Christopher Limawan; Gredion Prajena (co: Anderies; David; Muhammad Fikri Hasani)
DRAFT / SKELETON. Shape and argument only. Section V has table shells — no experiments run yet; every cell is a placeholder. Report nothing here as a result.
Framing (2026-08-07): TOPOLOGY-led (topic: Jaringan). Three-way: LuckPerms (industry standard, P2P notify-then-read) + LuckyCore (author's production predecessor, P2P push-data) vs NeoCore (author's full-scale master-slave gRPC system — replaces Atreus; 12,495 LOC, 13 TODOs, staging-tested). Security = one analytical metric (attack surface), not a threat model. Stated confound: topology and transport co-vary — whole architectures are compared, not one isolated variable.
Abstract
Multi-server game networks must keep per-player state — ranks, player lists, chat and mute state — consistent as it changes across many independent server processes. The near-universal design is a peer-to-peer topology in which every server is an equal participant that reads shared storage and broadcasts changes over Redis pub/sub, chosen largely by convention rather than measurement. The alternative is a master-slave topology in which one authoritative node owns the data and pushes changes to every replica. Which topology is better for this workload, and by how much, has not been measured. We present a controlled three-way comparison of the synchronization paths of three real systems, holding the data model, workload, and environment fixed: LuckPerms, the de-facto standard, which propagates a reload notification and reads data from shared storage; LuckyCore, a system deployed in production that pushes the change data over Redis pub/sub; and NeoCore, the author's master-slave gRPC system, which pushes over an authoritative master using bidirectional streaming. Using one measurement harness that drives each system's real code, we compare propagation latency, staleness, update loss and recovery, throughput, resource overhead — measured on both the network and the database, since these strategies shift cost differently — and failure behavior. We add one analytical metric, attack surface (the number of nodes holding data-store credentials), which differs structurally across the three. [RESULTS SENTENCE — from measured data.] The contribution is empirical evidence, against a recognized baseline, of the latency–robustness–cost trade-off among these strategies, and guidance on when a master-slave topology's added complexity and single point of failure are justified over peer-to-peer propagation in distributed game backends. Because transport and topology co-vary across the three systems, we compare whole architectures and state this confound explicitly.
Keywords: synchronization topology, distributed systems, peer-to-peer, master-slave, gRPC, Redis Pub/Sub, LuckPerms, attack surface, multiplayer game backend
(Bahasa abstract to be added for camera-ready if required.)
I. Introduction
In a sharded game network a player is on one server at a time; that server loads the player's permission attributes on join and holds them for the session — there is no full local replica. When an operator changes a rank, the change must reach whichever server hosts that player, fast and without a relog, and remain durable for future joins. This is a cache-coherence problem: propagate a mutable shared record to the (changing) set of nodes holding a live view of it.
In practice the ecosystem defaults to a peer-to-peer topology over Redis publish/subscribe, chosen by convention ("just use Redis"): every server is an equal participant, holds storage credentials, and may broadcast. The structural alternative is master-slave: one authoritative node owns the data, orders changes, and pushes them to replicas that hold no credentials. Three concrete strategies span these topologies, and they are rarely compared head-to-head:
- Peer-to-peer, notify-then-read (LuckPerms with its Redis messenger): publish a lightweight reload signal; each receiver reads the data from shared storage.
- Peer-to-peer, push-data (LuckyCore): publish the change data itself over Redis; receivers apply it directly.
- Master-slave, push-data (NeoCore): an authoritative master pushes the change to each replica over a persistent gRPC bidirectional stream.
This paper compares all three, using an unusual asset: two of them (LuckyCore, NeoCore) were built by the author for the same production network, and the third (LuckPerms) is the recognized third-party standard — so the comparison controls the domain while including a neutral baseline. LuckyCore was deployed at the core of a large Southeast Asian network in 2020; in production it accumulated four documented pain points (author's operational experience): messy code, bug-proneness, latency, and a trust model where every server can read, write, and broadcast. NeoCore, a full-scale master-slave gRPC system built on the same codebase lineage, reached staging, but the author resigned before it launched — so this paper asks whether the migration its design promised would actually have paid off.
Research questions.
- RQ1 (latency). How do propagation latency and its tail compare between peer-to-peer propagation (LuckPerms, LuckyCore) and master-slave propagation (NeoCore)?
- RQ2 (robustness). How do staleness, update loss, and recovery under node/broker/master failure differ?
- RQ3 (cost). How do throughput and overhead — on both network and database — compare on equivalent workloads?
- RQ4 (attack surface, analytical). How does the number of nodes holding store credentials (and able to write/propagate) differ structurally?
Contributions. (1) A domain-controlled, workload-equivalent methodology comparing peer-to-peer and master-slave synchronization topologies using three real systems, including a neutral industry baseline. (2) An empirical characterization across six dimensions — crucially measuring database cost, not just wire cost. (3) One analytical structural metric (attack surface). (4) Guidance framed generally enough to transfer beyond games.
II. Background and Related Work
Cross-server state in game backends. Proxy networks sync player state via shared Redis; RedisBungee was the canonical example (now discontinued). Such solutions are engineering practice, rarely measured.
LuckPerms — baseline, not just related work. LuckPerms is the de-facto permission plugin; its messaging service (Redis, RabbitMQ, SQL-polling, or plugin messaging) pushes a reload signal after a change, and receivers reload the affected user from shared storage — the data is not carried in the message. We include it as a measured baseline, comparing only its propagation path; LuckPerms does far more (contexts, inheritance, wildcards), which we do not evaluate.
Publish/subscribe vs streaming RPC. Redis pub/sub is at-most-once, fire-and-forget, no persistence/replay. gRPC bidirectional streaming enables server-initiated push with acknowledged connection state and keepalive, at the cost of a central component and connection management.
Consistency and cost. Framed as cache coherence, the trade-off is latency vs. staleness vs. resource cost — and, notably, which resource (network vs. database) each strategy taxes. [Cite Tanenbaum & van Steen; gRPC, Redis, LuckPerms docs.]
Topology in distributed systems. Peer-to-peer/leaderless designs favour availability and operational simplicity but give up a global ordering point and distribute trust widely; leader/master designs gain ordering, acknowledged writes and a natural authorization choke point at the cost of a single point of failure. This trade-off is well studied in databases and consensus systems but has not been characterized for game-backend state propagation.
Gap. Prior art shows how to sync game state but does not compare topologies, and typically ignores database cost and trust distribution. We measure both.
III. System Design
(Full version with diagrams in system-design.md.) Three propagation strategies for the same problem:
- LuckPerms (peer-to-peer): write DB → publish reload notification → receiver reads DB.
- LuckyCore (peer-to-peer): write DB → publish change data over Redis pub/sub → receiver applies from packet (fire-and-forget).
- NeoCore (master-slave): change sent to the master → persist → push over PubSubRPC bidi stream → receiver applies (acknowledged; keepalive + reconnect). Slaves (dataloader) hold no store credentials; a PlayerList RPC syncs online-player sets.
Key structural differences (full table in system-design.md §5): what is sent (signal vs data), where the receiver gets data (DB vs message), authority (none vs master), DB load per propagation (LuckPerms +1 read/receiver vs ~0), and nodes holding store credentials (N, N, 1).
IV. Methodology
Approach. Experimental comparative study. One harness with three pluggable backends drives each system's real code under identical conditions. NeoCore reached staging but never production (author resigned before launch; only 13 TODO markers, so it is largely complete) → its path is extracted and instrumented, and the staging-not-production status is disclosed. LuckPerms runs in small real Bukkit servers (it is built to live in-server) while LuckyCore/NeoCore paths are extracted headless — this asymmetry is disclosed.
Testbed. N receivers + one origin, co-located on one host sharing a monotonic clock (one-way latency, no skew). All three use the same MySQL.
Workload. A generator emits permission-change ops (setRank, setPrefix, ...) at controlled rates; vary fleet size N, update rate, payload.
Metrics (six empirical + one analytical).
1. Propagation latency: t_apply − t_commit (mean/p50/p95/p99).
2. Staleness window; 3. update loss + recovery (incl. induced disconnect).
4. Throughput (sustained changes/s).
5. Overhead — network bytes/change AND database reads/change (fairness-critical: LuckPerms shifts cost to the DB), plus CPU/mem.
6. Failure recovery: kill DB / broker / master; recovery time + ops lost.
7. Attack surface (analytical): count nodes holding store credentials / able to write/propagate — determined from architecture, not run.
Threats to validity. Specific implementations (mitigated by mechanism-level framing); single-host testbed (optional emulated-latency condition); NeoCore is staging-tested, not production-proven; LuckPerms-in-server vs extracted-headless asymmetry — all disclosed. Attack surface is analytical, not a penetration test.
V. Evaluation
⚠️ PLACEHOLDER — no experiments run. Shells only; report nothing here as a finding.
A. Propagation latency (RQ1).
| System | mean (ms) | p50 | p95 | p99 |
|---|---|---|---|---|
| LuckPerms (P2P, notify + DB read) | — | — | — | — |
| LuckyCore (P2P, Redis pub/sub) | — | — | — | — |
| NeoCore (master-slave, gRPC) | — | — | — | — |
B. Staleness & update loss (RQ2).
| System | steady-state loss | loss during disconnect | recovery |
|---|---|---|---|
| LuckPerms | — | — | reload on next notify (DB backstop) |
| LuckyCore | — | — | next re-read |
| NeoCore | — | — | reconnect + refetch |
C. Throughput & overhead (RQ3). Figures: latency vs N; latency vs rate. Overhead table (report BOTH):
| System | wire bytes / change | DB reads / change | CPU/mem |
|---|---|---|---|
| LuckPerms | small (notification) | +1 per receiver | — |
| LuckyCore | full data | ~0 | — |
| NeoCore | full data | ~0 | — |
D. Failure recovery (RQ2). Recovery time + ops lost when DB / broker / master is killed.
E. Attack surface (RQ4, analytical).
| LuckPerms | LuckyCore | NeoCore | |
|---|---|---|---|
| Nodes holding store credentials | N | N | 1 |
| Nodes able to write/propagate directly | N | N | 1 |
(One honest sentence: NeoCore's transport is currently plaintext/unauthenticated; the advantage is credential distribution — channel hardening (TLS/auth) is future work.)
F. Discussion. [Interpret results.] Hypotheses to test: push strategies (LuckyCore, NeoCore) should beat notify-then-read (LuckPerms) on latency; LuckPerms should be loss-tolerant (DB backstop) but load the database; NeoCore should recover cleanly but adds a master SPOF. The useful output is a latency ↔ robustness ↔ cost triangle with the industry standard anchored — plus the network-vs-DB cost finding.
G. Generalizability. As session-affine cache invalidation, the trade-off applies beyond games — microservice caches, edge invalidation, collaborative apps. Minecraft is the testbed, not the boundary.
VI. Conclusion and Future Work
We compared three player-data synchronization strategies — notify-then-read (LuckPerms), push-over-pub/sub (LuckyCore), and push-over-gRPC (NeoCore) — under a domain-controlled methodology with a neutral baseline. [One-sentence conclusion.] Future work: removing the master SPOF (multi-master/consensus), acknowledged/replayable pub/sub delivery, channel hardening for the mediated design (TLS/auth), and geo-distributed validation.
Acknowledgment
LuckyCoreV5 was developed and operated for LuckyNetwork; thanks to [collaborators] for the production system.
References (representative — finalize in IEEE)
- gRPC Authors, "gRPC Documentation," grpc.io.
- Redis Ltd., "Redis Pub/Sub," redis.io/docs.
- LuckPerms, "Syncing data between servers" / "Messaging Services" docs.
- RedisBungee project (discontinued) documentation/archive.
- A. S. Tanenbaum and M. van Steen, Distributed Systems: Principles and Paradigms.
- Google, "Protocol Buffers Documentation."
- [Add: a state-replication / pub-sub-vs-RPC paper; a cache-coherence reference.]