送信者がイーサネットを介して比較的大量のデータ（たとえば1秒あたり数メガバイト）を同じサブネット上の適度な数の受信者（たとえば12未満）にマルチキャストする必要がある場合、最も効率的なプロトコルは何ですか？信頼できるとは、パケットが失われた場合に、プロトコルによって、受信者でデータが失われないようにパケットが確実に再送されることを意味します。効率という用語を定義するのは非常に困難ですが、スループットを最大化し、両端のCPU使用率を抑えてネットワーク帯域幅を最小化するとします。それはまだ明確な定義ではありませんが、私が思いつくことができる最高のものです。ストリーム指向またはメッセージ指向のプロトコルのいずれかが受け入れられます。
実際の例をいただければ幸いです。長所と短所を説明できれば、主観的な回答、つまりお気に入りのマルチキャストプロトコルは何ですか。
実際の例: TIBCO Rendezvous。
データは、シーケンス番号を付けてマルチキャスト経由で送信されます。欠落しているシーケンス番号を検出したクライアントは、マルチキャスト グループで「パケット 12345 を逃しました」というメッセージを送信します。サーバーはそのデータを再マルチキャストします。サーバーには、クライアントが要求した場合に備えて、構成可能な量のデータをバッファリングできます。
問題：
パケットの半分をドロップする 1 つのクライアントと、100 の正常なクライアントがあるとします。このクライアントは、1 つおきのパケットに対して再送信要求を送信します。サーバーは、正常なクライアントの 1 つに十分な負荷をかけ始め、パケットのドロップと再送信の要求を開始します。それによる余分な負荷により、別の正常なクライアントが再送信を要求し始めます。等々。輻輳崩壊が発生します。
Tibco は、再送信要求が多すぎるサブスクライバーを切断する回避策を提供しています。これにより、単一の加入者が輻輳の崩壊を引き起こすことが難しくなります。
輻輳崩壊のリスクを制限するもう 1 つの回避策は、サーバーが再送信するデータの量を制限することです。
また、Tibco は、再送信要求をマルチキャストまたはユニキャストするかどうか、および再送信自体について、クライアントとサーバーにヒューリスティックを提供する必要があります。彼らはしません。(サーバーの場合、特定の時間枠内に 1 つのクライアントのみが再送信を要求した場合、再送信をユニキャストできます。クライアントの場合、サーバーが再送信パケットで、要求しているのが自分だけであることを通知した場合、再送信要求をユニキャストできます。再送信し、将来的にリクエストをユニキャストしてください)
基本的に、クライアントがデータを受信することをどの程度強く保証したいかと、輻輳崩壊のリスクとの間で決定する必要があります。パケットがドロップされた場所と、再送信がユニキャストとマルチキャストのどちらで最も効率的に送信されたかを推測する必要があります。サーバーがデータを理解し、送信する更新されたデータがある場合に再送信を送信しないことを決定できる場合 (再送信は無関係になります)、Tibco RV などのフレームワークよりもはるかに優れた立場にあります。
データを理解すると、間違った仮定につながる場合があります。たとえば、市場データ - 更新されたクオートがある場合、クオートを再送信しなくても最初は問題ないように思えるかもしれません。しかし、後で、サブスクライバーが現在の見積もりを追跡しようとしているだけでなく、見積もりの履歴を保持していたことに気付く場合があります。サブスクライバーによって要件が異なる可能性があり、一部のクライアントはマルチキャスト TCP よりもユニキャスト TCP を好む場合があります。
ある時点で、再送信や遅いクライアントの場合にバッファするデータの量をサーバーで任意に決定する必要があります。
TIBCO に続く PGM プロトコルは、オープン スタンダードの信頼性の高いマルチキャストであり、ネットワーク エレメント アクセラレーションを使用して非常に大規模で効率的に動作するように多くの最適化が行われています。PGM は TIBCO と CISCO によって開発されたもので、TIBCO Rendezvous の下にあるオプションのプロトコルです。デフォルトのプロトコルは、設計が非常に似ている TRDP です。
PGM についてここにリストされているような理論上の効率を計算できます。
http://code.google.com/p/openpgm/wiki/PgmPerformance
残念ながら、実際のネットワーク要素、NIC、および一般的なコンピューター アーキテクチャのパフォーマンスは、理論上の最大値よりもはるかに低くなります。
BitTorrent！
いいえ、真剣に。あなたはそれを読みたいかもしれません。
UDPはマルチキャストに役立ちますが、探している保証は提供されません-BitTorrentは、元のソースから複数の完全なコピーを送信する必要がありますが、それでもかなり効率的であり、特にチェックサムの量を考慮すると、有用な保証を提供します渡されるデータの各「チャンク」で実行されます。
UFTPをお勧めします。NAK ベースのメカニズムを使用して再送信するパケットを決定し、固定送信レートまたはTFMCCを使用した輻輳制御のオプションがあります。
各ファイルはパスで送信されます。最初のパスではファイル全体が送信され、後続のパスでは再送信のみが送信されます。各クライアントは、どのパケットを受信し、どのパケットを逃したかを追跡します。特定のチェックポイント (およびパスの最後) で、受信者が最後のチェックポイント以降にパケットを逃した場合、逃したパケットをリストする NAK を送信します。これには、低損失レシーバーが高損失レシーバーの前に終了するという利点があります。UFTP は、NAK のパーセンテージが特定のしきい値を超える受信者をドロップするように構成することもできます。
損失を示した受信者のみに NAK を制限することにより、受信者のフィードバックによって送信者が圧倒される輻輳崩壊のリスクが軽減されます。
開示: UFTP の作成者。
複数のクライアントへの信頼性の高い同時送信が本当に必要な場合は、UDP / マルチキャストの代替としてStream Control Transmission Protocolを検討する必要があると思います。
これは未解決の研究課題です。利用可能な商用ソリューションがありますが、法外に高価です。幸運を。