Roadmap — Three-way Topology Comparison (Jaringan)

Progress (2026-08-07): ALL THREE BACKENDS MEASURED. Tracks A, B and C are done — see
findings-lcore-vs-neocore.md §1-24. Latency, fan-out, bytes, ordering, loss and database cost
are all measured on a quiet host (seven-server, 8 cores, load ~1.4). Remaining work is writing,
not measuring: fill Results (E2), finalise Related Work (E3), IEEE format (E4).

Locked decisions (2026-08-07)

Framing: TOPOLOGY-led — peer-to-peer vs master-slave. (Earlier "Redis vs gRPC" transport framing was dropped: it names the wrong variable and is confounded.) Topic: Jaringan.
Artifact is NeoCore, not Atreus. NeoCore = 12,495 LOC, 101 Java files, 13 TODO markers (Atreus had 138), pure gRPC (no Redis), master-slave (rpc-master + dataloader slaves), reached staging. Far more likely to actually run.
Three systems: LuckPerms (P2P, notify-then-read-DB) + LuckyCore (P2P, push-data over Redis) vs NeoCore (master-slave, push-data over gRPC).
Stated confound: topology and transport co-vary. Compare whole architectures; isolating one variable = future work. Say this explicitly in Batasan + Threats to Validity.
Security = ONE analytical metric (attack surface: nodes holding credentials, N/N/1). No threat model, no hardening build.
Production baseline = LuckyCore only. NeoCore never launched (author resigned). Frame as: "does the migration its design promised actually pay off?"

The one rule

Fair comparison = all three in ONE harness, three pluggable backends driving each system's real code, same workload/clock/host/MySQL. Any number comes from a fresh instrumented run.

Metrics — 6 empirical + 1 analytical

#	Metric	Type
1	Propagation latency (mean/p50/p95/p99)	empirical
2	Staleness window	empirical
3	Update loss + recovery (incl. induced disconnect)	empirical
4	Throughput (changes/s before backlog)	empirical
5	Overhead — network AND database (fairness-critical: LuckPerms trades wire bytes for DB reads)	empirical
6	Failure recovery (kill DB / broker / master)	empirical
7	Attack surface (nodes w/ credentials: N, N, 1)	analytical

Track A — NeoCore

[x] A1. Get NeoCore running headless (effort M, risk M — lower than Atreus) — rpc-master + N dataloader slaves, no Minecraft. Only 13 TODOs and it ran in staging, so expect config/wiring work rather than resurrection.
[x] A2. Instrument the propagation path (effort S–M) — timestamp at origin commit and at slave apply on PubSubRPC / PlayerList; latency histogram (HdrHistogram), ops counter, CSV out.

Track B — LuckyCore parity

[x] B1. Extract LCore's Redis path (effort M, risk M) — RedisHandler + Packets publish/subscribe into a standalone harness. Reuse real code.
[x] B2. Wire into the shared harness (effort S–M).

Track C — LuckPerms baseline

[x] C1. Stand up LuckPerms sync (effort M, risk M — heaviest) — real LuckPerms + Redis messenger + shared MySQL across N small Bukkit servers. Start early.
[x] C2. Instrument (effort S–M) — trigger change via API/command; observe when other servers reflect it; count DB reads per propagation (metric 5).

Track D — Shared harness

[ ] D1. Three-backend harness (effort M) — one workload generator + measurement layer.
[ ] D2. Testbed (effort S–M) — co-located, shared monotonic clock, same MySQL.
[ ] D3. Failure injection + full sweep (effort M) — kill DB/broker/master; warm-up, k repeats, vary N and rate.

Track E — Analytical + paper

[x] E1. Attack-surface table (effort S) — credential-holding nodes per system + the plaintext caveat.
[ ] E2. Fill Results from real runs. (gated on A–D)
[ ] E3. Related Work — LuckPerms (fairly: messenger pushes reload signals, data in storage), RedisBungee (discontinued).
[ ] E4. IEEE format, abstracts, references; with advisor: venue + deadline + co-authorship.

Order / critical path

D1 + D2 (harness skeleton) — everything depends on it.
Parallel: A1/A2 (NeoCore), B1/B2 (LCore), C1/C2 (LuckPerms — start first, heaviest).
E1 anytime (analytical, no dependency).
D3 → E2 → E3/E4.

New findings that changed the plan: the fan-out sweep is the strongest result so far (origin
throughput collapses ~30x for the master-slave design while the broker stays flat), and a stalled
receiver revealed that the master has no gRPC flow control, so it buffers without bound. Both are
written up in findings-lcore-vs-neocore.md and belong in the evaluation. Two harness lessons:
each simulated receiver needs its OWN gRPC channel (shared channels hide fan-out behind HTTP/2
multiplexing), and receivers must ping every ~2s or the master drops them after 5 quiet seconds.

Biggest risk: three runnable systems. NeoCore's 13 TODOs make Track A much safer than the old Atreus plan. If scope slips, LuckyCore is the droppable one (LuckPerms is the more relevant baseline) → falls back to a two-way P2P-vs-master-slave comparison.