mirror of
https://github.com/DarkflameUniverse/DarkflameServer.git
synced 2026-10-02 02:43:44 +00:00
332bc04ce8
Staff arm a packet capture on the dashboard; master passes MESSAGE_CAPTURE_CONTROL ARM to every world, auth and chat and arms its own. Each server's PacketCapture tap (dServer receive, and a send hook in RakPeer::Send so replica constructions are seen too) records into one preallocated chunk per server and ships sealed chunks through master on the main loop when capture_flush_bytes or capture_flush_interval_ms is reached; past capture_buffer_max_mb the oldest chunks are dropped and the dashboard records a gap. Nothing is armed: one flag check. - targets: an account (from its login; packets before the login are kept per connection and added once auth or the world knows whose they are), a character (from when it is picked), or everything; up to 8 at once (a bit each in the record mask) - worlds and auth record their clients' packets and the master link messages of a captured player (session keys by name, zone transfers by request, player added/removed, migration); chat finds the player in each packet; master records server traffic for everything - secrets are never recorded: structs that carry them (login request, login response user key, world validation session key, session key messages between servers) are read, blanked and written again before recording; auth keeps only the handshake and login - PacketDecoder: a registry by service and message id names every packet and decodes the registered structs; CaptureBundle is the file format (DLUBNDL1, metadata, records); CaptureTools orders records on one timeline, pulls movement out, makes bundles portable or anonymous and diffs replays - the dashboard keeps packet captures in message_capture_sessions (capture_kind 1) and their packets in a file under capture_dir, one write per batch; arming is audited - MESSAGE_CAPTURE_CONTROL/DATA only gain appended enum values and trailing fields Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
41 lines
1.6 KiB
C++
41 lines
1.6 KiB
C++
#pragma once
|
|
|
|
#include <cstdint>
|
|
#include <filesystem>
|
|
|
|
struct MessageCaptureData;
|
|
|
|
/**
|
|
* Packet captures and their replay on the dashboard (docs/CaptureReplay.md), next to the game message inspector
|
|
* (Inspector.h) and under the same permission (dev_message_inspector).
|
|
*
|
|
* Staff arm a capture for an account (from its next login, or at once if it is online), one character, or
|
|
* everything; every server records its part (PacketCapture.h) and sends batches through master. The dashboard keeps
|
|
* each capture's session in message_capture_sessions (capture_kind 1) and its packets in a bundle file under
|
|
* capture_dir (CaptureBundle.h), written once per batch, never per packet. Viewing decodes the saved bytes with the
|
|
* server's packet structs (PacketDecoder.h); positions feed the World 3D replay; a capture exports as a portable
|
|
* bundle for the capture tool's replay.
|
|
*/
|
|
namespace CaptureReplay {
|
|
// After the database is up: captures that were running when the dashboard stopped are marked ended
|
|
void Initialize();
|
|
|
|
void RegisterRoutes();
|
|
|
|
// MESSAGE_CAPTURE_DATA with status PACKETS, via master
|
|
void HandleData(const MessageCaptureData& data);
|
|
|
|
// Main loop: writes batches, pushes to browsers, re-arms and ends captures on time
|
|
void Update();
|
|
|
|
// Writes what is waiting and closes the files
|
|
void Shutdown();
|
|
|
|
// Whether a packet capture is still recording
|
|
bool IsRunning(uint64_t sessionId);
|
|
|
|
// Where capture files are kept (capture_dir, relative to the server's folder), and one capture's file
|
|
std::filesystem::path Folder();
|
|
std::filesystem::path FileOf(uint64_t sessionId);
|
|
}
|