Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#5,926 コメント 2 件 リアクション 4 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
32/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust

調査の方向性

まず、WebSocket プロトコルの処理と SDK のメッセージ定義を追跡します。この issue では特定のファイルやテストは指定されていません。提案されている Ping メッセージと Pong メッセージを、既存の WebSocket Ping の動作および関連する issue #5525 と #5357 と比較します。完了条件には、通常のクエリ処理を測定せずに、プロトコルのサポートと RTT、ジッター、推定サーバー時間の SDK メトリクスを含める必要があります。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Rust
スター
25.2k
フォーク
1.1k
平均マージ
4日 2時間
マージ済み PR(30日)
41

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

clockworklabs/SpacetimeDB のほかの issue

clockworklabs/SpacetimeDB の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。