> ## Documentation Index
> Fetch the complete documentation index at: https://generaltranslation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 切断時の対処

<div id="what-is-a-disconnection">
  ## 切断とは何ですか？
</div>

ストリーミング API への接続を確立するとは、非常に長時間にわたって維持される HTTPS リクエストを行い、そのレスポンスを逐次的にパースすることを意味します。`powerstream` エンドポイントに接続する際は、HTTPS リクエストを発行し、可能な限り長い間その結果として得られるストリームを受信し続ける必要があります。サーバー側のエラー、クライアント側の過度な遅延、ネットワーク問題、定期的なサーバーメンテナンス、重複ログインといった事態が発生しない限り、当社サーバーは接続を無期限に維持します。ストリーミングエンドポイントへの接続では、切断が発生する可能性が高く、その発生を前提として再接続ロジックを実装しておく必要があります。

<div id="why-a-streaming-connection-might-be-disconnected">
  ## ストリーミング接続が切断される可能性がある理由
</div>

ストリームはいくつかの理由で切断される可能性があります。失敗の原因を理解するには、ストリームから返されたエラーメッセージを確認してください。想定される切断理由は次のとおりです。

* 認証エラー (誤ったトークンや、誤った認証方式が使用されている場合など) 。
* X 側でストリーミングサーバーが再起動されることがあります。これは通常、コードのデプロイに関連しており、一般的に起こり得るものとして想定し、それを前提に設計しておく必要があります。
* クライアントがストリームから配信される投稿の量についていけていない、またはデータの読み取りが遅すぎる場合。すべてのストリーミング接続には、クライアントに送信されるメッセージのキューがあります。このキューが時間の経過とともに大きくなりすぎると、接続は閉じられます。
* アカウントが 1 日または 1 か月あたりの投稿数のクォータを超過した場合。
* 冗長なアクティブ接続が多すぎる場合。
* クライアントが突然データの読み取りを停止した場合。ストリームから読み取られる投稿のレートが突然低下した場合、接続は閉じられます。
* サーバーとクライアント間のネットワークの問題が発生している可能性。
* 一時的なサーバー側の問題、計画メンテナンスやアップデートが行われている場合 ([ステータスページ](/ja/status)を確認してください) 。

<div id="anticipating-disconnects-and-reconnecting">
  ## 切断を想定した上での再接続
</div>

投稿をストリーミングする場合、切断が発生し得ることを認識しつつ、可能な限り長時間接続を維持することが目標です。エンドポイントは 20 秒ごとにキープアライブのハートビート (改行文字のように見えます) を送信します。このシグナルを使って、切断されていないかどうかを検出してください。

1. 新しいコンテンツとハートビートの受信が止まったことを、コードで検出できるようにします。
2. そのような状況になった場合、コードは再接続ロジックをトリガーする必要があります。一部のクライアントや言語では読み取りタイムアウトを指定できるため、これを 20 秒に設定できます。
3. サービスはこれらの切断を検出し、可能な限り早く再接続する必要があります。

一度確立された接続が切れたら、すぐに再接続を試みてください。再接続に失敗した場合は、発生したエラーの種類に応じて再接続の試行間隔を伸ばしてください。

* TCP/IP レベルのネットワークエラーに対しては、線形バックオフを行います。これらの問題は一般的に一時的であり、すぐに解消される傾向があります。再接続までの遅延時間を試行ごとに 250ms ずつ増やし、最大で 16 秒まで延長します。
* 再接続が適切な HTTP エラーに対しては、指数関数的なバックオフを行います。最初は 5 秒待機し、試行ごとに待機時間を 2 倍にして、最大で 320 秒まで延長します。
* HTTP 429 エラー (レート制限超過) に対しては、指数関数的なバックオフを行います。最初は 1 分待機し、試行ごとに待機時間を 2 倍にします。なお、HTTP 429 を受信するたびに、アカウントに対するレート制限が解除されるまで待機しなければならない時間が延長されることに注意してください。
   

<div id="recovering-lost-data">
  ## 失われたデータの復旧
</div>

切断が発生した場合でも、取り逃した可能性のあるすべてのデータを確実に取得できるようにするために利用できる、いくつかの方法があります。取り逃したデータを復旧するために実施できる主な手順については、[データの復旧](/ja/x-api/powerstream/recovery-and-redundancy) に関するインテグレーションガイドにまとめています。 
 

<div id="rate-limits-and-usage">
  ## レート制限と使用状況
</div>

接続制限を確認するには、レスポンスに含まれる 3 つのヘッダーを参照します。これは、ルール用エンドポイントを何回使用できるか、およびストリーミングエンドポイントに対して何回再接続が許可されているかを把握するのに役立ちます。

* `x-rate-limit-limit` は、15 分間のウィンドウ内でクライアントが実行できるリクエスト数の上限を示します。

* `x-rate-limit-remaining` は、15 分間のウィンドウ内で残っているリクエスト回数を示します。

* `x-rate-limit-reset` は、15 分間のウィンドウがいつ再開されるかを示す UNIX タイムスタンプであり、その時点で `x-rate-limit-remaining` は 0 にリセットされます。

filter stream エンドポイントは現在、使用状況データを報告しません。どれだけの投稿が配信されたかを確認するには、必要に応じて処理量を計測して一時停止できるように、メータリングロジックをコードに実装してください。 

ストリームのクライアント側をホストするコードは、受信した投稿を先入れ先出し (FIFO) キューまたは類似のメモリ構造に単に挿入し、別のプロセスやスレッドがそのキューから投稿を取り出して解析し、保存のために内容を準備します。この設計により、受信する投稿の量が大きく変化した場合でも効率的にスケールできるサービスを実装できます。概念的には、HTTP 経由で無限に長いファイルをダウンロードしていると考えることができます。

<div id="reconnection-best-practices">
  ## 再接続に関するベストプラクティス
</div>

<div id="test-backoff-strategies">
  ### バックオフ戦略をテストする
</div>

バックオフの実装をテストするよい方法は、意図的に無効な認可用資格情報を使用し、再接続の試行を観察することです。適切に実装されていれば、429 応答を一切受け取りません。

<div id="issue-alerts-for-multiple-reconnects">
  ### 複数回の再接続に関するアラート
</div>

クライアントが再接続間隔の上限しきい値に達した場合、接続に影響している問題を切り分けられるよう、通知を送信するようにしてください。

<div id="handle-dns-changes">
  ### DNS 変更への対応
</div>

クライアントプロセスが DNS の Time To Live (TTL) を順守しているか確認してください。スタックによっては、解決済みアドレスをプロセスの実行中ずっとキャッシュしてしまい、指定された TTL の範囲内での DNS 変更を反映しないものがあります。このような過度なキャッシュは、X が IP アドレス間で負荷を切り替える際に、クライアント側でサービス中断を引き起こす原因となります。

<div id="user-agent">
  ### User Agent
</div>

`user-agent` HTTP ヘッダーにクライアントのバージョンを必ず含めてください。これは X 側で問題を診断するうえで非常に重要です。実行環境の制約により `user-agent` フィールドを設定できない場合は、代わりに `x-user-agent` ヘッダーを設定してください。