think
16px
820px
← all files

Project Brief — BINUS Thesis (Artikel Ilmiah): Player State Synchronization Topologies

Purpose of this file: complete context for continuing this thesis project in a fresh environment (e.g. Claude Projects). Everything here is established fact from the working sessions of 2026-07-13 → 2026-08-07. The companion documents listed in §9 carry the full detail.

1. Student & administrative facts

  • Author: Efran Nathanael — NIM 2602151891, Computer Science, BINUS Kemanggisan, telp 085211332390. GitHub BadAccuracyID (aka LyraMS). Former Minecraft network developer (LuckyNetwork / Lucky Development Department), now CEO of Datahive.
  • Course: COMP6861001 Thesis, 2025 Even Semester, Non-Class track, type Artikel Ilmiah (~6-page conference paper; an A requires actual conference acceptance, so it must survive peer review).
  • Topic (BINUS list): Jaringan / Networking.
  • Calon pembimbing: Douglas Rakasiwi Nugroho (D6957) — requested, not yet approved. Others listed on the form: S2 Christopher Limawan (D6954), S3 Gredion Prajena (D4459); Co-S: Anderies (D6657), David (D4498), Muhammad Fikri Hasani (D6421).
  • Proposal skripsi: filled into the official SOCS template and delivered 2026-08-07 → Proposal_Skripsi_Efran_Nathanael.docx (link in §9). Uses real Word numbered lists and Heading 2/3 styles; printed Daftar Isi indexes only Bab headings (template TOC field is \o "1-1"); user must right-click → Update Field in Word for page numbers.

2. The paper in one paragraph

A controlled three-way comparison of player-state synchronization topologies in multi-server game networks: peer-to-peer pub/sub (LuckPerms = notify-then-read; LuckyCore = push-data over Redis pub/sub) versus master-slave gRPC streaming (NeoCore = authoritative master pushes over bidirectional streams). One fair measurement harness drives each system's real code under identical workload, clock, host, and MySQL. Six empirical metrics (propagation latency, staleness, update loss/recovery, throughput, overhead measured on BOTH network AND database, failure recovery) plus one analytical metric (attack surface = number of nodes holding store credentials: N / N / 1). Output = the latency–robustness–cost trade-off map, anchored by a neutral industry baseline.

Final titles.
- ID: STUDI KOMPARATIF TOPOLOGI SINKRONISASI STATE PEMAIN: PUB/SUB PEER-TO-PEER DAN gRPC STREAMING MASTER-SLAVE PADA JARINGAN GAME MULTI-SERVER
- EN: A COMPARATIVE STUDY ON PLAYER STATE SYNCHRONIZATION TOPOLOGIES: PEER-TO-PEER PUB/SUB VS. MASTER-SLAVE gRPC STREAMING IN MULTI-SERVER GAME NETWORKS

Research questions: RQ1 propagation latency P2P vs master-slave · RQ2 consistency & robustness (staleness, loss, recovery under node/broker/master failure) · RQ3 cost (throughput + network AND database overhead) · RQ4 attack surface (structural/analytical).

3. The three systems (all real, two are the author's own)

LuckPerms LuckyCore (LCore) NeoCore
Role Industry-standard baseline (3rd party, neutral) Author's production system (2020) Author's successor system (2022)
Topology Peer-to-peer Peer-to-peer Master-slave
Mechanism Notify-then-read: Redis notification, receivers re-read shared DB Push-data: change data broadcast over Redis pub/sub, fire-and-forget Push-data: master persists then pushes over gRPC bidirectional stream (PubSubRPC), keepalive + reconnect
Store credentials Every server (N) Every server (N) Master only (1); slaves (dataloader) hold none
Status Actively maintained OSS Ran in production at a large SEA Minecraft network (2020) Reached staging, never production (author resigned before launch)

Key architecture facts about NeoCore: ~12.5k LOC / 101 Java files, pure gRPC (zero Redis), 5 protos (NeoCore = PubSubRPC bidi + PlayerList; Logger; GlobalChat; PrivateChat; Commons), @RPCMessage/@RPCListener annotation API, MultiAddressNameResolverFactory client-side failover. It was forked from Atreus (the author's earlier gRPC permission-sync system) and still depends on Atreus at runtime for rank lookups (client-api 0.6, RPCServer.loadAtreus()). It also hard-depends on NovenaInjector (the author's ~180-line Java agent) to inject downloaded libs at startup (-javaagent). Do NOT call NeoCore "Atreus's successor" — say "the author's full-scale master-slave gRPC system".

4. Non-negotiable framing & honesty rules

  1. Topology-led, not transport-led. Transport (Redis vs gRPC) and topology (P2P vs master-slave) co-vary across the systems — a stated confound. The paper compares whole architectures; isolating one variable = future work. State this in Batasan and Threats to Validity.
  2. Security stays light. Attack surface is ONE analytical countable metric, not a threat model. The author is explicitly not comfortable defending deep cybersecurity framing; do not re-propose a security-led paper. Honesty caveat that must always accompany the attack-surface claim: NeoCore's transport today is plaintext gRPC with no authn/authz (and trusts a spoofable requesterServer string), so the delivered benefit is credential separation only; TLS/auth = future work.
  3. Fair-comparison rule: all systems measured by ONE harness with pluggable propagation backends driving each system's REAL code (no reimplementation), same workload/clock/host/MySQL. LuckPerms runs in small real Bukkit servers; LuckyCore/NeoCore sync paths are extracted headless (disclose this asymmetry, and that LCoreBench is a faithful extraction because RedisHandler is Bukkit-coupled).
  4. Never fabricate results. Draft result sections use explicit placeholders. Report where NeoCore LOSES (it loses broadcast fan-out badly) as prominently as where it wins.
  5. The author's old "~5000 qps" recollection is unverified — never cite it; everything gets re-measured.
  6. RedisBungee is discontinued — don't cite as a live example.

5. Real results already measured (2026-08-07, on bench/instrumentation branch)

These exist but are deliberately NOT in the proposal (a proposal precedes results). Full write-up: findings-lcore-vs-neocore.md (§1–11).

  1. Fan-out collapse is the headline. NeoCore origin throughput for 5000-msg broadcast: ~44,646 msg/s at N=0 → ~2,120 at N=8 → ~1,412 msg/s at N=30 (~30x collapse, ~linear per receiver; master loops onNext per observer). LuckyCore is FLAT in N (broker absorbs fan-out). Topology consequence, not transport.
  2. Targeted sends INVERT it. NeoCore sendMessage(msg, target): ~9–12k msg/s FLAT in fleet size; ~5.6x cheaper than its own broadcast at N=8. LuckyCore has no addressing (all subscribers receive everything, filter client-side, N−1 wasted deliveries). So master-slave wins targeted traffic as decisively as it loses broadcast → the honest bottom line is a mix-dependent crossover.
  3. Bytes: per-message gRPC leaner (106 B vs 140 B), but broadcast origin sends N copies vs 1 → crossover at N=2; at N=16 it's 12x. A per-message-only comparison would conclude the opposite — call this out.
  4. Ordering: NeoCore 0 inversions (master serializes). LuckyCore 18/1225 pairs inverted, all in the first ~8 messages (cold-start of RedisHandler's cached thread pool); steady state clean but unguaranteed.
  5. Loss during disconnect: both lose everything (no buffering/replay in either). Difference: NeoCore NOTICES within ~5s (keepalive) and the slave refetches state on reconnect; LuckyCore neither notices nor recovers. Neither is a durable log — say so plainly.
  6. Backpressure CORRECTION (supersedes an earlier wrong claim): a stalled (SIGSTOPed) receiver gets EVICTED by the 5s keepalive cleaner → master memory stays flat (bounded; crude load shedding). The untested residual case: a receiver that keeps pinging but never drains (master never checks isReady).
  7. Implementation gap found in NeoCore: private chat uses broadcast though it targets one player on one server — textbook targeted case; one-line fix, ~5.6x effect at N=8. Frame as implementation gap, NOT topology limit.
  8. Harness gotchas (hard-won): each simulated receiver MUST have its own gRPC ManagedChannel (HTTP/2 multiplexing on a shared channel hides fan-out cost — measured FASTER, a trap); receivers must ping every ~2s or the master silently evicts them after 5 quiet seconds (report EFFECTIVE receiver counts); benchmark host must be quiet — valbox (load 13+, 12 cores) inflated p95/p50 ~19x, so real runs need a dedicated machine; record nproc + loadavg per run.

6. Instrumentation & harness (built, verified end-to-end)

  • NeoCore side (branch bench/instrumentation, commit d374e3d): BenchmarkHelper (master; tags msgs BENCH_ID+BENCH_SENT_AT via System.nanoTime(), writes send CSV), BenchmarkCommand (benchmark start/run/stop), PubSubHelper.sendBenchmarkMessage() (bare tagged send), BenchmarkRecorder (client; -Dneocore.benchmark=<id>). Raw CSV; percentiles offline. Off by default. Two pre-existing NeoCore bugs found+fixed along the way (CLI command scan missed the debug package; NPE on bare filename in Files.createDirectories).
  • LuckyCore side: harness/lcore/LCoreBench.java — faithful extraction (jedis 3.3.0 + gson 2.8.6 pinned to LCore's versions, same envelope {identifier, packetData} on channel LuckyCore, same cached-thread-pool async publish). Must be disclosed as an extraction.
  • CSV schema (both): sender run_id,bench_id,action,receivers,sent_at; receiver client,bench_id,action,sent_at,received_at,latency_ns; rows join on bench_id.
  • NeoCore build quirks: repoint dead nexus.velocitypowered.com → repo.papermc.io; build :rpc:jar first; rpc-master needs VERSIONINFO resource; needs MySQL (LiteBans failure is non-fatal) and -javaagent:NovenaInjector.jar; master boots: "Listening on port 50051".

7. Remaining work (roughly in order)

  1. Real measurement runs on a QUIET host (cheap dedicated-vCPU VPS, <$1 total): latency distributions, ≥3 reps with variance, Method-A fan-out at 16/32.
  2. LuckPerms backend: small real Bukkit servers + LuckPerms Redis messenger, same CSV instrumentation (heaviest remaining harness work).
  3. Staleness + failure-injection experiments (kill broker/master/DB; disconnect/reconnect recovery timing). DB-overhead measurement (reads per propagation — LuckPerms shifts cost to DB).
  4. The "pings but never drains" backpressure edge case (needs a two-thread client).
  5. Write the Artikel Ilmiah into the IEEE conference A4 template (saved in templates/conference-template-a4.docx); pick a target conference (needs acceptance for an A).

8. Working conventions (matter for any generated output)

  • No AI attribution anywhere in the thesis artifacts: commits authored as "Efran Nathanael" with no co-author trailer; generated code must match house style (@UtilityClass, Gson JsonObject, switch-arrow, sparse comments) and not read as AI-written.
  • Proposal/deskripsi field has a hard <1000-char cap (final desc = 954 chars, in proposal-fields.md).
  • Mermaid on the x056 renderer: plain ASCII only, no semicolons in diagram text (breaks rendering).
  • The author prefers ADHD-friendly communication: lead with the action/answer, numbered steps, short lists, one next action.
  • Obscura (employer's DMS) was rejected as a thesis artifact over AI-authorship/IP concerns — do not resurrect it.

9. All project links (x056.think.val.id)

Document Link
Proposal skripsi (.docx, filled BINUS template) https://x056.think.val.id/Proposal_Skripsi_Efran_Nathanael.docx
This brief https://x056.think.val.id/claude-projects-brief.md
Proposal form fields (titles, desc, RQ, batasan — FINAL) https://x056.think.val.id/proposal-fields.md
System design (3 architectures, diagrams, audit findings §7–10) https://x056.think.val.id/system-design.md
Harness design (pluggable backends, instrumentation, lessons) https://x056.think.val.id/harness-design.md
Roadmap (Tracks A–F, progress, risks) https://x056.think.val.id/roadmap.md
Paper skeleton (IEEE-shaped draft, placeholder results) https://x056.think.val.id/artikel-ilmiah-draft.md
Measured findings §1–11 (the real data) https://x056.think.val.id/findings-lcore-vs-neocore.md
Harness README (how to run both benches) https://x056.think.val.id/README.md
Threat model (de-scoped; reference only for the attack-surface metric) https://x056.think.val.id/threat-model.md

Local working tree (not reachable from Claude Projects): /home/efran/remote-development/atreus-lcore-paper/ (docs + harness + templates), /home/efran/remote-development/NeoCore (branch bench/instrumentation), LuckyCore & repos via SSH key as BadAccuracyID (public API 404s the private repos).