ストリームとデータグラム
MoQT の Object（配送の単位となるひとまとまりのデータ）は、ストリーム（SUBGROUP ストリーム、draft-ietf-moq-transport-22 11.3.1）か、1 つの QUIC DATAGRAM（OBJECT_DATAGRAM、11.2.1）のどちらかで購読者に届きます。 データグラムとストリームの配送 では両方を 1 つずつ送りました。 このページでは、その違いがアプリにとって何を意味するかを説明します。
それぞれの方式が保証すること
Section titled “それぞれの方式が保証すること”| ストリーム | データグラム | |
|---|---|---|
| 失われたパケット | 届くかリセットされるまで再送される | 失われたまま。再送されない |
| 順序 | 1 本のストリームの中では順番どおり | 保証なし |
| Object の大きさ | 16384 バイト未満にする。複数回に分かれて届く Object を保持するハブのバッファーの大きさ（WIRED_MOQTRUN_RELAY_FRAG_MAX） |
QUIC パケット 1 つ分 |
| 途中から参加した購読者 | 送信中のストリームでも、ハブは中継できる | 購読後に送られたデータグラムだけを受け取る |
| ハブが持つ中継の状態 | パブリッシャーのストリームごとに中継エントリー（WIRED_MOQTRUN_MAX_RELAYS、Track ごとに 4 本） |
なし |
データグラムは、フレーミングを含めて QUIC パケット 1 つに収まる必要があります。 RFC 9000 14 が経路に求めるのは 1200 バイトの UDP ペイロードを運べることだけなので、経路がそれ以上を運べると分かっていない限り、データグラムの Object はそれより十分小さくします。
ヘッドオブラインブロッキング
Section titled “ヘッドオブラインブロッキング”1 本のストリームのバイト列は順番どおりに届けられるので、パケットが 1 つ失われると、再送が届くまで同じストリームの後続のバイトがすべて待たされます。 これがヘッドオブラインブロッキングです。 一方、ストリーム同士は互いを待たせません。 ある Group のストリームで損失が起きても、次の Group のストリームは流れ続けます。 Group ごとにストリームを 1 本使う配置（MoQT へのメディアの載せ方 を参照）を勧めるのはこのためで、損失が遅らせるのはその Group の残りだけになります。 データグラムには復元すべき順序がないので、損失が他のデータグラムを遅らせることはなく、購読者は失われたものを受け取らないだけです。
配送のタイムアウト
Section titled “配送のタイムアウト”信頼性のあるストリームは、もう役に立たなくなった Object を後から届けることがあります。 購読者は、SUBSCRIBE か REQUEST_UPDATE に OBJECT_DELIVERY_TIMEOUT パラメーター（draft 9.20.4）を付けて、これを抑えられます。 Object の最初のバイトがハブに届いてからタイムアウトより長く経っていれば、ハブはそれを遅れて送る代わりに、その購読者のストリームを DELIVERY_TIMEOUT でリセットします（draft 5.2）。 0 でない SUBGROUP_DELIVERY_TIMEOUT も同じように働きます。発行者も Track Property で設定していれば、2 つのうち小さいほうを使います。
どちらを選ぶか
Section titled “どちらを選ぶか”- データグラムは、次のフレームが失われたフレームの代わりになる、小さく頻繁なメディアに向きます（音声フレーム、カーソル位置、センサーの値など）。
- ストリームは、欠けずに、または順番どおりに届く必要があるものに使います。 映像の Group（デコーダーはキーフレーム以降のすべてのフレームを必要とします）、チャットメッセージ、添付ファイル、パケット 1 つに収まらない Object がこれにあたります。
- タイムアウト付きのストリームは、遅れが積み上がる代わりに次の Group へ飛んで品質を落とすべき、ライブ映像に向きます。