この記事では、マルチキャストメッセージの信頼性の高い配信を提供する最も一般的なプロトコルについてお話したいと思います。 このプロトコルはPGM（実用的な一般的なマルチキャスト）と呼ばれます。 LBT-RM（29westから）やSmartSockets（TIBCO Softwareから）など、IPマルチキャストを介した他の信頼性の高いプロトコルは、何らかの形でPGMの修正または実装です。
ネットワークソフトウェアおよびハードウェアにおける他の多くの優れた革新と同様に、PGM仕様はシスコシステムズ内で作成されました。 信頼できるマルチキャストを標準化するプロセスで解決しようとした主な問題は、ネットワークの輻輳に対する制御と保護です。 輻輳は通常、リスナーによって明らかに処理できなかったメッセージや、プロトコルの有効な帯域幅を減らす過剰なサービスパケットが原因で発生する可能性があります。
TCPで使用される原則は、インターネットが効率的に機能するため、マルチキャストには適していません。 TCPでは、TCPメッセージの送信者がリスナーに適応できるように、送信されたがまだ確認されていないデータの量（送信ウィンドウ）を動的に変更できます。 これは、リスナーが多く、送信者が一人の場合には適切でないことは明らかです。
パッケージの種類
まず、用語を定義しましょう。 プロトコルには、次のパケットタイプが含まれます。
ODATA-マルチキャスト経由で送信されるペイロード（IPマルチキャスト）
NAK-不足しているODATAをパスツリーの次のノードに発見したリスナーの一意性（通常はUDP）によって送信される否定応答のあるパケット
NCF-受信したNAKの確認。ツリーノードは、NAKを受信したサブネット内のすべてのリスナーにマルチキャストで送信します
RDATA-データパケットは、受信したNAKに応じて、マルチキャストトピックで送信者が発行したODATAによって複製されます
SPM-パスおよびハートビートメッセージ。パケットはマルチキャストで定期的に公開され、ODATAパケットがない場合
プロトコルの主な機能
例を見てみましょう。100台の手押し車のグリッドがあり、それぞれに非常に異なるハードウェアとオペレーティングシステムがあります。 これらの車で実行されているアプリケーションにさまざまな短い時間間隔（株価など）でメッセージを送信するサーバーアプリケーションを開発しています。 この場合に一意のトランスポートプロトコルを使用するとは、各クライアントのデータをコピーすることを意味します。 パッケージの送信の複雑さは、サブスクライバーの数の増加とともに直線的に増加します。 マルチキャストは、1つのパケットを複数のリスナーに送信し、送信側のソケットバッファーに1つのレコードのみを作成できるすばらしいテクノロジーです。パケットはルーターにコピーされます。 したがって、リスナーの数が増えても、パケットの配信時間には影響しません。
これは素晴らしいことですが、問題があります。UDPのようなマルチキャストは、配信とパケットの順序を保証しません。 取引所での取引から遠く離れている人でさえ、あるシンボルの割り当てを逃すアプリケーションに何が起こるかを推測することは難しくないと思います。 加入者がいくつかの戦略に従って自動的に売買するロボットである場合、クォータを受信しないと、ロボットは価格が変更されたことを認識せず、悪い取引を生み出す可能性があります。 配信を保証する最も自然な方法は、TCPのように肯定的な確認応答を使用することです。 しかし、ここで2つの問題が発生します。1つ目は、サーバーが各サブスクライバーからの確認を処理する必要があることです。つまり、複雑さが再び線形になり、2つ目はパケットが頻繁に失われる場合の同じデータの大量のマルチキャストです。
PGMプロトコルは、受信した各メッセージを確認する代わりに、このプロトコルが欠落している各メッセージを確認する（否定確認）という事実によって、最初の問題を解決します。 各プロトコルパケットにはシーケンス番号が含まれており、PGMリスナーは、シーケンス番号の1つがスキップされたことを検出すると、パケット送信者に一意の確認を送信します。 シリーズの最後のパケットを失う可能性（テールロス）を排除するために、有用なメッセージがないPGMソースは特別なパケット（リスナー側で現在のシリアル番号を維持することをタスクとするハートビート）を送信します。
2番目の問題を解決するために、PGMは、マルチキャストメッセージの各送信者からリスナーへのパスツリーを保存し、最新の状態に保ちます。 各ツリーノードはパケットの送信元を認識しており、ツリーのリーフ（マルチキャストメッセージのリスナー）がパケットが受信されなかったことを検出した場合、失われたパケットの確認はリーフからツリーのルート（マルチキャストメッセージの送信者）に到達できます。 ツリーの各ノードで状態が設定されます。つまり、サブネット上でパケットが失われます。 再度送信する場合、この状態が設定されていないノードでは失われたパケットを無視でき、パケットが失われたサブネットのみに到達します。 パスツリーの維持は、各送信者が定期的にマルチキャストグループに送信するパスメッセージによって実現されます。
メッセージを混同して、現在のシリアル番号またはハートビットとメッセージパスを維持しないでください。 これらはリスナーに配信される情報を複製しますが、パスのメッセージは定期的に送信され、ビートビットはより複雑なアルゴリズムに従って送信されるという点で異なります。 Hertbitsは、初期HertbitタイムアウトとHertbitsの数の2つのパラメーターによって設定されます。 最初のハートビートは、最後のパケットの後のタイムアウト後に送信されます。 2番目のHerbitは、前のHertbitの2倍後に送信されます。 そして、適切な量のhertbitが送信されるまで。
概略的には、次のようになります。
| ____ | _________ | __________________ | _________________________________ | ____
時間t->
ここで、最初のダッシュは最後のペイロードパケットであり、残りはヘルトビットです。
ナックストーム
PGMのすべてが一見滑らかに見えるわけではありません。 PGMを使用しようとする多くの人は、NAKストームと呼ばれる問題のためにこれを落とします。 ストッククォータが送信されるネットワークの例に戻ると、リスナーの1つが遅すぎてソケットバッファーからデータを読み取る時間がなかった場合、NAKが発生する可能性があります。 バッファが詰まっているため、着信パケットは無視され、そのようなクライアントは多くのNAKパケットを送信します（ベビーレシーバーを泣かせます）。 これに対応して、送信者はRDATAパケットを発行する必要があります。これにより、送信者とそのすべてのマルチキャストサブスクライバーの負荷が増加し、その一部は低速クライアントにもなります。 NAKストームは、PGMパケットの単一のソースが多くのリスナーを持つことができるという点で危険です。 1つのNAKを処理してRDATAパケットを送信すると、ソースは別のリスナーから同じODATAパケットでNAKをすぐに受信できます。 さらに、ODATAパケットの損失を検出したリスナーは、NCFを受信するまでNAKを送信します。 ネットワーク帯域幅のほとんどがODATAではなくNAK、NCF、およびRDATAの転送に費やされるため、これはすべてプロトコル効率の大幅な低下につながる可能性があります。
PGMプロトコルには、ネットワーク内のさまざまな種類の輻輳の悪影響を減らすためのメカニズムがいくつかあります。 ソースが受信するNAKの数は、マルチキャストメッセージ用の特別なリスナー-NAKアグリゲーター（指定レシーバー）を使用して減らすことができます。 このようなアグリゲーターは、サブネット上のNAKをリッスンし、サブネット全体からソースに1つのNAKのみを送信します。 サブネットからNAKを独立して集約できるルーターがあります;これらはPGMルーターです。
PGMでは、特別なネットワーク要素（指定されたローカル修理業者または指定されたローカル再送信機）の存在も許可され、NAKへのRDATAパケットで個別に応答できます。 これにより、低速クライアントが他のサブネットからのリスナーの動作に影響を与えないトポロジを構築できます。
PGMでは、さまざまなオプションを設定することもできます-タイムアウトNAKを抑制するためのタイムアウトとカウンター。 これらのタイムアウトの選択は別の魔法であり、PGMを操作する全体の複雑さにあります。 リスナー側では
- パケット損失検出から最初のNAKが生成されるまでの経過時間
- NCFが受信されなかった場合、NAKを再送信する前に経過した時間
- RDATAを受信しなかった場合、NCFを受信してから新しいNAKを送信するまでに経過する時間
- リスナーが送信できるNAKの最大数
送信者側では、これ
- 最初のNAKを受信してからRDATAを送信するまでに経過した時間
- RDATAの送信後に重複したNAKが無視される時間
- RDATAパケットが送信されるレートの制限（バイト/秒）
一般に、上記から、応答時間が短いシステム（低遅延システム）を開発するときにPGMとそのバリエーションがそれほど人気を博した理由を推測することは難しくないと思います。 このプロトコルは、肯定的なパケット確認応答を使用する信頼できるプロトコルよりも応答時間が短く、応答時間を低下させることなくメッセージリスナーの数を増やすことができます。
思考のための質問。 GFSとHadoopが信頼できるマルチキャストの代わりにTCPを使用するのはなぜですか？ すべてのデータがGFSおよびHFSに少なくとも3つの異なるボックスに複製されることは既知の事実です。 ネットワーク機器でパケットを複製するよりも、ソケットからソケットへパケットをコピーする方が本当に効率的または信頼性が高いですか