制限、タイムアウト、クォータ

Cloudflare Realtime の制限とタイムアウトを把握すると、アプリケーションの性能と信頼性を最適化しやすくなります。このセクションでは、Cloudflare Realtime をアプリへ組み込むときに知っておくべき主な制約と挙動を説明します。

Free

セッションあたりの API: 各セッションで 1 秒あたり最大 50 回の API 呼び出しができます。レート制限はアプリ単位ではなく、セッション単位です。
API 呼び出しあたりのトラック: 1 回の API 呼び出しで最大 64 本のトラックを追加できます。セッションへさらにトラックを追加する場合は、複数の API 呼び出しに分けます。
セッションあたりのトラック: セッションが持てるトラック数に上限はありません。実質的な上限は、Cloudflare との間の接続帯域で決まります。
DataChannel の canReply の排他: ある publisher DataChannel に対して canReply を持てる subscriber は、同時に 1 つまでです。別の subscriber に canReply を付与すると、直前の選択は置き換わります。publisher が受け取るのは逆方向のトラフィックだけであり、ほかの subscriber へはファンアウトされません。詳細は publisher への返信（canReply）を参照してください。

トラックのタイムアウト: トラックは 30 秒間非アクティブだと自動でタイムアウトし、ガベージコレクションされます。非アクティブとは、Cloudflare がメディアパケットを受け取っていない状態です。この仕組みにより、そのトラックを使うすべてのセッションでリソースを効率よく使い、セッションをきれいに保てます。
DataChannel の確認応答タイムアウト: リモート DataChannel で waitForAck を有効にしている場合、subscriber はチャネル作成から 30 秒以内に最初のメッセージ（確認応答）を送る必要があります。送らないと、SFU はゲートされたチャネルを破棄し、メッセージを転送しません。再試行するには、リモート DataChannel を作り直します。

セッションの状態: セッションに対する操作（トラックの pull や push など）では、PeerConnection の状態が connected である必要があります。操作はこの状態を最大 5 秒待ち、タイムアウトします。これにより、メディア伝送に関与するのはアクティブで利用可能なセッションだけになります。

インターネット接続の考慮: クライアントと Cloudflare の間でインターネット接続が切れる可能性は、運用上の前提です。セッションを続けるには、検出と再接続の戦略を実装することを推奨します。接続状態を監視するため、バックエンドサーバーへ定期的なハートビートを送る方法があります。接続の問題を検出したら、自動で再接続し、新しいセッションを確立してください。セッションとトラックはタイムアウトまで 30 秒間再利用できます。この短い間に再接続を試みられます。

これらの制限を守り、タイムアウトの挙動を理解すると、アプリケーションを応答性と安定性を保ったまま、スムーズなユーザー体験を提供しやすくなります。

Cloudflare Realtime は次のコーデックに対応しています。