mirror of
https://github.com/openfrontio/OpenFrontIO.git
synced 2026-06-25 23:44:37 +00:00
181368f962
## Summary The game simulation runs **client-side**, so the server can't directly see what's happening in a running game. This adds a way for the admin bot to observe a live game: clients report a live stats snapshot every ~10s, the server reaches consensus on it (reusing the winner's vote mechanism), and a new admin-bot endpoint serves it. ## How it works 1. **`LiveStatsController`** (client) emits a snapshot every **100 turns** (~10s at 100ms/turn) — only deterministic sim values, with players sorted by clientID, so in-sync clients produce an identical payload. 2. The snapshot is sent as a new **`live_stats`** wire message wrapping a `LiveStats` object (`turn` + per-human-player `tilesOwned`/`troops`/`gold`/`isAlive`/`team`). 3. **`GameServer.handleLiveStats`** tallies a per-turn **IP-weighted majority vote** — the same consensus the winner uses — and keeps the latest agreed snapshot. 4. **`GET /api/adminbot/game/:id/stats`** returns it, enriched with usernames the server already holds. `liveStats` is `null` until the first consensus. The winner's vote tally was extracted into a small reusable **`VoteRound`** (`src/server/VoteTally.ts`) and is now used for both winner and live-stats consensus. Names are deliberately **excluded** from the voted payload (they vary per client under name anonymization, which would break exact-match consensus); the server joins `clientID → username` instead. ## Changes - `src/server/VoteTally.ts` *(new)* — reusable IP-weighted `VoteRound` - `src/core/Schemas.ts` — `PlayerLiveStatsSchema`, `LiveStatsSchema`, `ClientSendLiveStatsSchema` + unions - `src/client/controllers/LiveStatsController.ts` *(new)* — per-100-turn snapshot reporter - `src/client/Transport.ts` — `SendLiveStatsEvent` + sender - `src/client/hud/GameRenderer.ts` — register the controller - `src/server/GameServer.ts` — refactor winner onto `VoteRound`; add live-stats consensus + `liveStats()` accessor - `src/server/AdminBotRoutes.ts` — `GET …/stats` endpoint ## Testing - **Unit:** `tests/server/VoteTally.test.ts` (majority/dedup/ties), `tests/server/LiveStats.test.ts` (consensus, disagreement, per-client dedup, stale-turn rejection, turn advance, out-of-sync exclusion, + endpoint 200/404/400). Full suite green (`npm test`), typecheck + lint clean. - **Manual e2e** against the dev server: created an admin-bot game, joined it in a browser, force-started via `toggle_game_start_timer`, and confirmed `GET …/stats` returned the consensus snapshot with username enrichment and an advancing `turn`. Also verified wrong-worker → 400 and missing-key → 401. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
86 lines
2.9 KiB
TypeScript
86 lines
2.9 KiB
TypeScript
import { describe, expect, it } from "vitest";
|
|
import { ClientMsgRateLimiter } from "../../src/server/ClientMsgRateLimiter";
|
|
|
|
const CLIENT_A = "clientA" as any;
|
|
const CLIENT_B = "clientB" as any;
|
|
|
|
const SMALL = 100;
|
|
|
|
describe("ClientMsgRateLimiter", () => {
|
|
describe("intent messages", () => {
|
|
it("allows intents within limits", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
expect(limiter.check(CLIENT_A, "intent", SMALL)).toBe("ok");
|
|
});
|
|
|
|
it("limits when per-second count exceeded", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
for (let i = 0; i < 10; i++) {
|
|
expect(limiter.check(CLIENT_A, "intent", SMALL)).toBe("ok");
|
|
}
|
|
expect(limiter.check(CLIENT_A, "intent", SMALL)).toBe("limit");
|
|
});
|
|
|
|
it("rate limits are per client", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
for (let i = 0; i < 10; i++) {
|
|
limiter.check(CLIENT_A, "intent", SMALL);
|
|
}
|
|
expect(limiter.check(CLIENT_B, "intent", SMALL)).toBe("ok");
|
|
});
|
|
|
|
it("allows intents up to MAX_INTENT_SIZE", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
expect(limiter.check(CLIENT_A, "intent", 2000)).toBe("ok");
|
|
});
|
|
|
|
it("kicks intents exceeding MAX_INTENT_SIZE", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
expect(limiter.check(CLIENT_A, "intent", 2001)).toBe("kick");
|
|
});
|
|
});
|
|
|
|
describe("non-intent messages", () => {
|
|
it("does not rate-limit non-intent messages", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
for (let i = 0; i < 20; i++) {
|
|
expect(limiter.check(CLIENT_A, "winner", 50)).toBe("ok");
|
|
}
|
|
});
|
|
|
|
it("does not rate-limit ping messages", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
for (let i = 0; i < 20; i++) {
|
|
expect(limiter.check(CLIENT_A, "ping", 50)).toBe("ok");
|
|
}
|
|
});
|
|
});
|
|
|
|
describe("total bytes limit", () => {
|
|
it("kicks when cumulative bytes reach 5MB", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
const chunkSize = 1024 * 1024; // 1MB
|
|
// Send 4 chunks = 4MB, should be ok
|
|
for (let i = 0; i < 4; i++) {
|
|
expect(limiter.check(CLIENT_A, "other", chunkSize)).toBe("ok");
|
|
}
|
|
// 5th chunk pushes to 5MB, should kick
|
|
expect(limiter.check(CLIENT_A, "other", chunkSize)).toBe("kick");
|
|
});
|
|
|
|
it("byte tracking is per client", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
const almostFull = 5 * 1024 * 1024 - 1;
|
|
expect(limiter.check(CLIENT_A, "other", almostFull)).toBe("ok");
|
|
// CLIENT_B should still be fine
|
|
expect(limiter.check(CLIENT_B, "other", 100)).toBe("ok");
|
|
});
|
|
|
|
it("kicks on bytes regardless of message type", () => {
|
|
const limiter = new ClientMsgRateLimiter();
|
|
const twoMB = 2 * 1024 * 1024;
|
|
expect(limiter.check(CLIENT_A, "intent", twoMB)).toBe("kick");
|
|
});
|
|
});
|
|
});
|