Skip to main content
配信は最大1回です — 再送はありません。切断中に確認されたものは再送されないため、プロダクションクライアントはギャップを検出し、それをバックフィルするかどうかを決定する必要があります。そのシグナルはcontext.slotです: 切断中に見逃したウィンドウの範囲を示します。このガイドでは、なぜ接続が切れるのか、どのようにクリーンに再接続するのか、そしてそれをどのように活用するのかを説明します。

接続が切断される理由

すべての切断には、何が起こったか、次に何をするべきかを示すWebSocketクローズコードがあります。 サーバーは15秒ごとにピングを行うため、健康だが静かな接続でもトラフィックが流れます。1分以上まったく何もない場合(通知もピングもない)— 接続が死んでいると仮定して再接続し、ソケットが教えてくれるのを待たないでください。

接続を維持する

フィルターが狭いために10分間マッチしない場合、10分未満の間隔で明示的にJSON-RPCのpingを送信します。
これは現在のスロットを返し、さらに重要なことに、アイドルタイマー用のクライアントメッセージとしてカウントされます。ライブラリレベルのWebSocketピンフレームはそうではありません。

再接続とギャップの検出

1

バックオフを伴う再接続

予想された場合でもされなかった場合でも、全ての切断で指数バックオフを伴って再接続します。サブスクリプションIDは再接続後も持続しないため、開いていたフィルターごとにparsedTransactionSubscribeを再送信します。
2

切断を越えてcontext.slotを追跡

切断前に見た最後のcontext.slotを保持します。再接続後に最初に見たスロットとそのスロットの間のギャップが、正確に見逃したウィンドウです — それ以上でもそれ以下でもありません。
3

必要に応じてバックフィル

アプリケーションがそのギャップを許容できない場合、RPCからそのスロットウィンドウをバックフィルしてください: 範囲内の取引を列挙するためにgetSignaturesForAddress、その後各取引を取得するためにgetTransactionを使用します。これは手動での調整ステップです — Parsed Streams自体は再生しません。
context.slotは再接続後も残るもので、切断前に完全に処理した最高のスロットを追跡し、それ以降のものをバックフィルウィンドウとして扱います。

JSON-RPCエラーの処理

失敗したリクエストは結果の代わりにJSON-RPCエラーを返すため、error.codeで分岐できます。 -32602および-32000は、リクエスト自体が間違っていることを意味します - フィルターを修正し、そのまま再試行しないでください。-32001および-32002は一時的なものです。同じバックオフを使って再接続します。

次のステップ

クイックスタート

フルプロトコルリファレンス: メソッド、フィルターフィールド、制限。

ジュピタースワップのトラッキング

この接続がサブスクライブできるフィルターを構築します。