4

次のシナリオがあります。ホストHostRec：

1）ホストのNIC bond0がマルチキャストグループmulticast1およびmulticast2に参加しました–アプリケーションがこれを要求したためです。2）同じホストHostRecでマルチキャストリスニングアプリケーションを起動します。このアプリケーションは、multicast3とUDPポート3でトラフィックをリッスンします。3）別のホストHostSendでマルチキャスト送信アプリケーションを開始します。

この時点で、次の3つのシナリオがあります。

a）ステップ3の送信アプリケーションがマルチキャストアドレスmulticast3およびudp port3で公開している場合、メッセージは上記のステップ2で開始されたリスニングアプリケーションによって正しく受信されます。これは予想される動作です。

b）マルチキャスト送信アプリケーションがmulticast2とport3でメッセージを公開した場合、それらのメッセージは、ステップ2で開始されたリスニングアプリケーションによって引き続き受信されます。マルチキャスト送信アプリケーションがマルチキャスト1とポート3でメッセージを公開する場合も同じ動作です。この動作は間違っています。

c）送信側アプリケーション（ステップ3）がマルチキャストアドレスmulticast4およびudp port3で公開を開始した場合（HostRecのNIC bond0がこのマルチキャストグループに参加していない場合）、メッセージはステップ2で開始されたリスニングアプリケーションによって正しく受信されません。これも予想される動作です。

ホストのマルチキャストカーネル構成に問題があるかどうかを提案できますか？

uname -a Linux HostRec 2.6.18-164.2.1.el5＃1 SMP Mon Sep 21 04:37:42 EDT 2009 x86_64 x86_64 x86_64 GNU / Linux

ありがとう、ソマリオ

4

1 に答える 1

4

最初は少し奇妙に見えますが、これは予想される動作です。マルチキャストグループ/ポートにバインドしていると思いますが、実際に行っていることは次のとおりです。

  1. インターフェイスのUDPポートへのバインド。
  2. このインターフェイスを特定のマルチキャストグループにサブスクライブします。

これらの2つのアクションは完全に独立しています。最初の結果は、プロセスがUDPであり、ポート/インターフェイス宛てのすべてのパケット（マルチキャストかどうか）を受信することです。2番目の結果は、特定のマルチキャストアドレスにアドレス指定されたパケットが（ネットワークルーターによって）インターフェイスに送信されることを保証することです。

ほとんどの人はこれを望んでいません。実際、彼らは単一のマルチキャストグループのデータを受信したいだけで、ネットワーク上で他に何が起こっているのかを心配したくないのです。これを実現する最善の方法は、1つのポートが1つのマルチキャストグループにのみ使用されるようにすることです。一般的な方法は、マルチキャストグループの最後のオクテットをポートの最下位オクテットとして使用することです。たとえば、224.0.0.22 /ポート19022、および224.0.0.150/19150。このようにして、間違ったデータを取得することはありません（これらのポートにUDPユニキャストデータを送信している人がいない限り）。

于 2012-08-06T07:06:38.120 に答える