context.slotです: 切断中に見逃したウィンドウの範囲を示します。このガイドでは、なぜ接続が切れるのか、どのようにクリーンに再接続するのか、そしてそれをどのように活用するのかを説明します。
接続が切断される理由
すべての切断には、何が起こったか、次に何をするべきかを示すWebSocketクローズコードがあります。
サーバーは15秒ごとにピングを行うため、健康だが静かな接続でもトラフィックが流れます。1分以上まったく何もない場合(通知もピングもない)— 接続が死んでいると仮定して再接続し、ソケットが教えてくれるのを待たないでください。
接続を維持する
フィルターが狭いために10分間マッチしない場合、10分未満の間隔で明示的にJSON-RPCのpingを送信します。
再接続とギャップの検出
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は一時的なものです。同じバックオフを使って再接続します。
次のステップ
クイックスタート
フルプロトコルリファレンス: メソッド、フィルターフィールド、制限。
ジュピタースワップのトラッキング
この接続がサブスクライブできるフィルターを構築します。