Skip to content

feat(network): Measure connection latency, jitter and loss with packet feedback - #657

Open
tintinhamans wants to merge 18 commits into
GeneralsOnlineDevelopmentTeam:mainfrom
tintinhamans:arctic/go/stack2/02-packet-feedback-measurement
Open

tintinhamans wants to merge 18 commits into
GeneralsOnlineDevelopmentTeam:mainfrom
tintinhamans:arctic/go/stack2/02-packet-feedback-measurement

Conversation

@tintinhamans

Copy link
Copy Markdown

Merge after #656.

There were no numbers for how a connection behaves beyond the lobby ping, and the only loss figure was a guess from command retries. ConnectionStats (new) keeps latency, jitter and loss of one connection over a 10 s window, and a retry whose earlier send was acked after all counts as a late ack, not as loss. The mesh also probes each peer on the ping channel, every connection.probe_lobby_interval_ms in the lobby (250) and connection.probe_match_interval_ms in a match (1000), timed from when the transport received the probe so a slow frame is not counted as network delay.

PacketFeedback (new) measures real packet loss per direction. Every game packet gets a sequence number and the receiver reports what it got over the last 64 packets, at most every 250 ms. It only sees byte buffers and a clock, so GNS, EOS or any other transport can share it.

Wire change: game packets start with a 3 byte envelope (u16 sequence, u8 flags) plus a 5 byte feedback record when due, and GENERALS_MAGIC_NUMBER is 0xF00E, so this build does not talk to an older one. A packet without a valid envelope, or on an unknown channel, is dropped. A failed GNS send is retried once and returned as a failure. The send.flags key is removed. The numbers show in the debug stats display.

Tested: builds x86 Release z_generals. The full stack had 0 CRC mismatches in 3 player rig runs, n=1.

xezon added 7 commits October 24, 2026 23:10
…ile::getFileInfo(), StdBIGFile::getFileInfo() (TheSuperHackers#3415)

(cherry picked from commit b805c12)
…File (TheSuperHackers#3505)

Both classes are identical apart from their name and contain no platform specific code.
Nothing in them depends on the BIG format either: they open a file from an offset and a
size inside the archive file. ArchiveFile takes over their functions and is no longer an
abstract class.

(cherry picked from commit 52a777a)
…ystem into BIGFileSystem (TheSuperHackers#3505)

Both classes are identical apart from their name and go through the local file system
for all file access. The one class that remains sits next to ArchiveFileSystem in
Core/GameEngine.

(cherry picked from commit e4b4d1e)
…e loadBigFilesFromDirectory (TheSuperHackers#3505)

loadMods refers to BIG files, which nothing else in ArchiveFileSystem does. It becomes a
virtual function that BIGFileSystem implements. loadBigFilesFromDirectory is renamed to
loadArchiveFilesFromDirectory, because the base class is not tied to one archive format.

(cherry picked from commit f299561)
@tintinhamans
tintinhamans force-pushed the arctic/go/stack2/02-packet-feedback-measurement branch from 0260a8d to 665be97 Compare October 25, 2026 11:15
@tintinhamans
tintinhamans force-pushed the arctic/go/stack2/02-packet-feedback-measurement branch from 665be97 to 2249a03 Compare October 25, 2026 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants