他のクライアントに確実にマルチキャストできるクライアントを考え出す必要があります。これは、マルチキャストグループ内のクライアント間で確実に接続するためにTCPを使用することを意味します。それはn^2の接続数になりませんか？それは私には少しばかげているようです。信頼性のあるマルチキャストをより簡単に行う方法はありませんか？
編集：UNIX / C
編集：マルチスレッドがどのように機能するかを明確にしませんでした。しかし、n ^ 2の接続を開くとしたら、マルチスレッド化することになり、それは私が望むよりもさらに複雑になると思いました。
信頼できるマルチキャストソリューションがいくつかあります。
私は最初の2つを試しました。
Normはシンプルで、標準のudpマルチキャストのように機能しますが、nacksが組み込まれています...それ以上必要ない場合は優れています。帯域幅の適応やその他の改善もサポートする実装がいくつかあります。
DDSは一歩前進です。それは本当に素晴らしく（私はRTIの実装を知っていて、それはうまく機能します）、多くの機能と非常に優れたデザインを備えています。これは、信頼性とフォールトトレランスに基づいており、オープンな実装があります。
ちなみに、少なくともDDSとNORMはn^2接続を必要としません。それらはマルチキャストUDPのように機能します。
ターゲットプラットフォームによって異なります。
PragmaticGeneralMulticastをご覧ください。これは、私が理解しているように、MicrosoftMSMQとTibcoRendezvousが使用するものであり、Winsockを介してアクセスできます（ http://msdn.microsoft.com/en-us/library/ms740125(VS.85).aspxを参照）。
OpenPGMを使用したPragmaticGeneralMulticast（PGM）を使用した高信頼マルチキャストの機能の1つとして、高速メッセージングシステムである0MQを確認する必要があります。
最近lwn.netに記事がありました：
マルチキャストとTCPは相互に排他的です。
UDPを介した信頼性の高い配信を実装するのは大変です。1980年代以降、これを行う人は誰もいません。パフォーマンスとBWオーバーヘッドの点で、安価なTCPスタックほど優れた方法を実行することは不可能です。訂正：手動で行われることもありますが、非常に長いパイプや細いパイプなどのエキゾチックなトランスポートでのみ行われます。
N^2接続はそれほどばかげていません。1Hzのキープアライブとの接続はそれほど費用がかかりません。費用はトラフィックです。これはあなたのデザインが焦点を合わせる必要があるものです。
上記のように、PGMはオプションです。私たちが抱えていた問題は、クライアントが着信データの読み取りに追いつかない場合、クライアントが切断されることです。
「十分に高速な」クライアントを確実に保証することはできなかったため、UDPマルチキャストの上に独自の信頼性プロトコルを実装しました。動的接続/切断に関しては、実装は完全に一般的ではありませんが、うまくいく可能性があります。ここで実装を見つけることができます：
http://www.equalizergraphics.com/cgi-bin/viewvc.cgi/trunk/src/lib/net/rspConnection.h?view=markup http://www.equalizergraphics.com/cgi-bin/viewvc.cgi /trunk/src/lib/net/rspConnection.cpp?view=markup
確かに、より効率的な方法があります。UDBを使い続け、信頼できる送信を自分で再実装します。しかし、些細なことではありません。ただし、少なくとも、送信されたパケットを送信サイトに1回だけ保持する必要があります。
考えただけですが、作業はネットワークプロトコルを使用して行う必要がありますか。また、パブリッシュ/サブスクライブベースのモデルを使用して、メッセージサービスでこれを実装することも検討してください。
ネットワークが必要な場合は、多くの接続に対処するか、自分で確実に配信する必要があります。その道を進む前に、要件を十分に確認してください。