Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#5,926 2 comentarios 4 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
32/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
backend-api-design, game-dev, networking

Línea de trabajo

Comienza rastreando el manejo del protocolo WebSocket y las definiciones de mensajes del SDK; el issue no menciona archivos ni pruebas específicos. Compara los mensajes Ping y Pong propuestos con el comportamiento existente de WebSocket Ping y los issues relacionados #5525 y #5357. La tarea terminada debe incluir compatibilidad con el protocolo y métricas del SDK para RTT, jitter y el tiempo estimado del servidor, sin medir el procesamiento normal de consultas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
25.2k
Forks
1.1k
Merge medio
3 d 17 h
PR fusionados (30 d)
45

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de clockworklabs/SpacetimeDB

Todos los issues de clockworklabs/SpacetimeDB

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.