context.slotです: 切断中に見逃したウィンドウの範囲を示します。このガイドでは、なぜ接続が切れるのか、どのようにクリーンに再接続するのか、そしてそれをどのように活用するのかを説明します。
接続が切断される理由
すべての切断には、何が起こったか、次に何をするべきかを示すWebSocketクローズコードがあります。
サーバーは15秒ごとにピングを行うため、健康だが静かな接続でもトラフィックが流れます。1分以上まったく何もない場合(通知もピングもない)— 接続が死んでいると仮定して再接続し、ソケットが教えてくれるのを待たないでください。
通知が少ないフィルターとアイドルタイムアウト
フィルターが十分に限定されていて、正当に10分間一致が発生しない可能性がある場合、サーバーがコード1000で接続を閉じることを想定してください。他の切断と同様に扱い、再接続して再サブスクライブし、以下の説明に従って欠落をバックフィルしてください。再接続と欠落の検出
1
Reconnect with Backoff
想定内かどうかにかかわらず、切断された場合は常に指数バックオフを使用して再接続します。サブスクリプションIDは再接続後に引き継がれないため、開いていたすべてのフィルターについて
parsedTransactionSubscribeを再送信してください。2
Track context.slot Across Disconnects
切断前に最後に確認した
context.slotを保持します。そのスロットと再接続後に最初に確認したスロットの間が、欠落した範囲と正確に一致します。それ以上でもそれ以下でもありません。3
Backfill if You Need To
アプリケーションが欠落を許容できない場合は、RPCからそのスロット範囲をバックフィルします。
getSignaturesForAddressで範囲内のトランザクションを列挙し、getTransactionで各トランザクションを取得します。これは手動の整合処理です。Parsed Streams自体は再送しません。context.slotです。切断前に完全に処理した最上位のスロットを追跡し、それより後のすべてをバックフィル対象の範囲として扱ってください。
JSON-RPCエラーの処理
失敗したリクエストでは、結果の代わりにJSON-RPCエラーが返されるため、error.codeに基づいて処理を分岐できます。
-32602と-32000は、リクエスト自体が誤っていることを示します。フィルターを修正し、そのまま再試行しないでください。-32001と-32002は一時的なエラーです。再接続時と同じバックオフを使用して再試行してください。
次のステップ
Quickstart
完全なプロトコルリファレンス:メソッド、フィルターフィールド、制限事項。
Track Jupiter Swaps
この接続でサブスクライブできるフィルターを作成します。