Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add a ping/pong Websocket message to support RTT and similar metrics

Aperta
  • Qualcosa non va?
#5,926 2 commenti 4 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
32/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend-api-design, game-dev, networking

Direzione di ricerca

Inizia tracciando la gestione del protocollo WebSocket e le definizioni dei messaggi dell’SDK; l’issue non indica file o test specifici. Confronta i messaggi Ping e Pong proposti con il comportamento esistente di WebSocket Ping e con le issue correlate #5525 e #5357. Il completamento dovrebbe includere il supporto del protocollo e metriche dell’SDK per RTT, jitter e tempo stimato del server, senza misurare la normale elaborazione delle query.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Game developers building on SpacetimeDB want to know their connection's round-trip time, how much it jitters, and what time the server thinks it is. These are pretty standard metrics for a game's networking layer, feeding lag compensation, interpolation and "ping" displays.

The server already sends WebSocket Ping frames, but browsers never expose control frames to JavaScript (as #5525 notes), and none of the SDKs surface them. So users are building their own: Pogly runs a ping/pong system on top of ours (see #5357). Others time reducer calls, which counts reducer queueing and runs a transaction every time. The /unstable/timestamp route (#2864) gives a clock reading, but over a separate HTTP connection.

We propose adding a dedicated Ping client message and Pong server message to the protocol. The Pong echoes the client's send time and adds the server receive Timestamp and how long the server held the message before replying. The server should answer Pings ahead of the normal message handler, which runs Subscribe and OneOffQuery inline, so the measurement doesn't include query evaluation.

The SDKs then derive the metrics below, using RFC 6298 smoothing for RTT and taking the clock offset from the lowest-RTT samples.

Metric Meaning
rtt Smoothed round-trip time (RFC 6298 SRTT)
rttLatest Most recent sample
rttMin Minimum over the recent sample window
jitter RTT variation (RFC 6298 RTTVAR)
serverNow() Estimated server Timestamp, on the same clock as ctx.timestamp; adjusts gradually and never goes backwards

Related:
This would be independent of QUIC support (#2619), but complementary. We need the RTT for Websockets regardless, but QUIC's independent datastreams would be a very natural fit.

Lingua principale
Rust
Stelle
25.2k
Fork
1.1k
Merge medio
3g 17h
PR unite (30g)
45

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di clockworklabs/SpacetimeDB

Tutte le issue di clockworklabs/SpacetimeDB

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.