問題タブ [multicast]

私はいくつかのiPodデバイス用にObjective-Cでプログラミングしていますが、何か疑問に思っていました。サーバークライアントモデルを利用するアプリケーションを開発しており、CソケットでUDPプロトコルを使用しています。iPodデバイスのIPアドレスを判別できるクラスはありますか？他のフォーラムを調べた後、何も見つかりませんでした。明らかにこのコマンドは機能しませんが、ipAddress=self.ipのようなものが私が念頭に置いていたものです。私はマルチキャストCソケットを設定していて、pingコマンドに似た回避策を実行しようとしています。これは、Objective-Cにも、私の知る限り（プログラミングしているだけなので、制限されています）には明らかに存在しません。少なくともこの夏の初めからObjective-Cで）。アドバイスやヒントはありますか？

概要:サーバーとクライアントをセットアップしました。どちらも UDP を使用して互いの検出を試みます。サーバーが起動すると、サーバーは稼働中であることを示すマルチキャスト メッセージ (239.1.1.1) を送信します。クライアントが起動すると、クライアントは自分が生きていることを示すマルチキャスト メッセージ (239.1.1.2) を送信します。サーバーとクライアントの両方が、互いのマルチキャスト メッセージにサブスクライブして、送信を受信します。このようにして、どちらのアプリケーション (サーバーまたはクライアント) が最初に起動するかに関係なく、どちらか一方にその存在が通知されます。

クライアント側では、次のことを行います。

1. サーバーから発信されたマルチキャスト メッセージをサブスクライブして受信するために、リッスン ソケットを設定します。
2. 
   以下の #3 に従って、クライアントのマルチキャスト メッセージに対するサーバー応答を受信する受信ソケットをセットアップします。
3. クライアントが実行しているマルチキャスト メッセージを (サーバーが受信して応答するように) 送信します。
4. #3 で送信されたクライアントのマルチキャスト メッセージに対するサーバーの応答を受信します。

質問:両方の受信ソケットがサーバーの (非マルチキャスト) 応答をクライアントに取得することを除いて、すべて正常に動作しています。これが予想される動作かどうかはわかりません。2 つの受信ソケットを 1 つに減らすことはできますか? #1 はサーバーのマルチキャストにサブスクライブし、#2 は同じポートでサーバーからの直接送信 (サーバーからの非マルチキャスト メッセージ) をリッスンするだけです。2 番目の受信ソケットを安全に取り外すことができますか?

以下のソース コードを参照してください (コード表示を簡略化するために例外処理を削除しました)。

クライアントコード:

サーバーコード:

すべて単一のサーバー プロセスに接続する必要があるクライアントがあります。クライアントがサーバーを見つけるために UDP 検出を使用しています。ディスカバリーの完了後に TCP/IP 接続を確立できるように、クライアントとサーバーで IP アドレスとポート番号を交換します。このようにして、パケット サイズは小さく保たれます。これは、UDP を使用して次の 2 つの方法のいずれかで実行できることがわかりました。

1. 各クライアントは、サーバーを探して独自のマルチキャスト メッセージを送信し、サーバーはそれに応答します。クライアントは、サーバーが応答するまで、このマルチキャスト メッセージの送信を定期的に繰り返すことができます (サーバーがダウンしている場合)。
2. サーバーは、定期的にマルチキャスト メッセージ ビーコンを送信します。クライアントはマルチキャスト グループにサブスクライブし、この方法でサーバーのマルチキャスト メッセージを受信して​​検出を完了します。

1. 多数のクライアントが存在する場合、最初は多数のマルチキャスト メッセージが送信されます (各クライアントから 1 つ)。サーバーのみがサブスクライブし、クライアントからのマルチキャスト メッセージを受信します。サーバーがクライアントに応答すると、クライアントはマルチキャスト メッセージの送信を停止します。すべてのクライアントがサーバーの検出を完了すると、マルチキャスト メッセージはネットワーク上で送信されなくなります。ただし、サーバーがダウンしている場合、各クライアントは、サーバーがバックアップされて応答できるようになるまで、間隔を置いてマルチキャスト メッセージ ビーコンを送信します。

2. では、サーバーのみが定期的にマルチキャスト メッセージ ビーコンを送信します。このメッセージは、マルチキャスト グループに加入しているすべてのクライアントにルーティングされることになります。クライアントがパケットを受信すると、クライアントの UDP リッスン ソケットが閉じられ、マルチキャスト グループに登録されなくなります。ただし、新しいクライアントがそれを検出できるように、サーバーはマルチキャスト ビーコンを送信し続ける必要があります。クライアントが必要な検出を行っているかどうかに関係なく、定期的にビーコンを送信し続けます。

ですから、どちらにもメリットとデメリットがあると思います。#1 は最初は負荷が高くなるように思えますが、最終的には負荷がゼロになります。#2 では、サーバーは永遠にビーコンを送信し続けます。

UDP とマルチキャストは私にとってかなり新しいトピックなので、どちらが好ましいアプローチで、どちらがネットワーク負荷を軽減するかを知りたいと思っています。

私はオブジェクトのセットを取得することを検討しています。たとえば、現在3つのオブジェクトが生きていて、それらはすべて共通のインターフェイスを実装し、それらのオブジェクトを4番目のオブジェクト内にラップして同じインターフェイスを実装するとします。

4番目のオブジェクトのメソッドとプロパティの実装は、これら3つの基になるオブジェクトの関連ビットを呼び出すだけです。ここではそれが意味をなさない場合があることを私は知っていますが、これはサービスマルチキャストアーキテクチャ用であるため、すでに適切な制限があります。

私の質問はどこから始めればよいかです。その4番目のオブジェクトの生成は、実行時にメモリ内で実行する必要があるためReflection.Emit、残念ながら、どこから始めればよいかを知るのに十分な経験がないのではないかと考えています。

インメモリアセンブリを構築する必要がありますか？確かにそのように見えますが、どこから始めるべきかを簡単に示したいと思います。

基本的に、私はインターフェイスと、そのインターフェイスをすべて実装するオブジェクトインスタンスのリストを取得し、新しいオブジェクトを構築し、そのインターフェイスを実装することを検討しています。これにより、すべてのメソッド呼び出しとすべての基になるオブジェクトへのプロパティアクセスが「マルチキャスト」されます。できるだけ少なく。例外などでたくさんの問題が発生しますが、それらに到達したら、それらのビットに取り組みます。

これはサービス指向アーキテクチャー用であり、例としてロガーサービスを使用する既存のコードを使用して、サービスを使用するコードを変更することなく、複数のロガーサービスにアクセスできるようにします。代わりに、複数の基になるオブジェクトの関連するメソッドを内部的に呼び出すだけのlogger-service-wrapperをランタイムで生成したいと思います。

これは、.NET 3.5およびC＃用です。

アプリケーションでマルチキャストを利用して、中間層に接続されたクライアントに更新を効率的にブロードキャストします。ネットワーク エンジニアから、「当社のマルチキャストはどのように機能するか」と、サポートされるマルチキャスト プロトコルについて、よく尋ねられます。私に関する限り、私たちのクライアント プロセスは、次のコマンドを発行することによって、マルチキャスト グループに参加するだけです。

そこには、どのマルチキャスト プロトコルを使用する必要があるかについての区別はありません。 この種の質問に私がどのように答えるかについて、何か有益な提案はありますか? 現時点では、マルチキャストに使用するアドレス/ポートを提供し、ネットワーク ルーターでこのアドレス/ポートを開くよう依頼するだけです。しかし、これでは十分ではないようで、より多くの情報が必要です (?)

同じホストで2つのTomcatインスタンスを実行します。各インスタンスは、RMIレプリケーションを介していくつかのehcacheキャッシュと通信しようとする同じWebアプリケーションを実行します。ehcacheで自動検出構成を使用しているので、どのホストとどのキャッシュを複製するかを明示的に定義する必要はありません。ehcacheインスタンスは、お互いを見つけて通信することはできません。

同じことを試しても、今回は各Tomcatインスタンスを別々のホスト（ボックス）で実行すると、すべてが魅力のように機能します。

インスタンスが同じホスト上にある場合、何か問題が発生していますか、それともマルチキャストによる自動検出ができませんか？

私の構成では、 RMI分散キャッシングのドキュメントに示されているデフォルトを使用しています。

そして、複製したい各キャッシュ領域内には、次のものがあります。

ありがとう

マルチキャスト アドレスに接続するネットワーク コードがいくつかありますが、数秒後に切断されます。このコードの何が問題なのか、誰でも理解できますか?

Connect() 関数が呼び出された後、接続済みとして報告されますが、1 ～ 2 秒待つと切断されます。間違ったポートなどにバインドしていますか? すべてのオンラインチュートリアルは、異なる方法でそれを行うようです.

MSMQ マルチキャストを使用している場合、(マルチキャストが有効な) キューがいくつかのメッセージを受信した後、マシンで一時的なネットワーク接続が失われた場合、接続が再確立されるとメッセージの受信が再開されます。ネットワークの停止期間が短い場合、キューはすべてのメッセージを受信します (受信マシンが切断されている間に送信されたものも含む)。ただし、期間が十分に長い場合 (数分)、一部のメッセージが失われます... 受信メッセージにギャップが生じます。

これは、MSMQ マルチキャストが信頼できる (ただし、配信が保証されていない) ため、予想される動作です。私の質問は、データが失われたときに MSMQ が情報を公開するかどうかです。私の理解が正しければ、PGMは既に「回復不能なデータ損失」を検出できますが、MSMQ はこの情報を公開しますか?

1 つの考えは、送信ごとにインクリメントされる各メッセージに整数を含めることです。これにより、受信者は（個々の送信者からの）メッセージのギャップを検出できます。しかし、PGM はすでにこれを行っていると思います。PGM/MSMQ が既にこれを検出できる場合、アプリケーション レベルでこれを追加したくありません。

助言がありますか？

最近、マルチキャスト送信パフォーマンスの分析を完了しました。幸い、JavaとCは、WindowsとSolarisで異なるトラフィック送信速度をテストしたため、ほぼ同じように機能しました。

ただし、送信間の時間が長くなると、マルチキャストメッセージを送信する時間が長くなることに気付きました。sendを頻繁に呼び出すほど、send呼び出しを完了するのにかかる時間は短くなります。

このアプリケーションを使用すると、sendを呼び出すまでの待機時間を制御できます。以下では、パケット間の遅延が増加するにつれて時間が増加します。1000パケット/秒（1ミリ秒の待機時間）を送信する場合、送信を呼び出すのに13マイクロ秒しかかかりません。1パケット/秒（1000ミリ秒の待機時間）では、その時間は20マイクロ秒に増加します。

この現象は、JavaとCの両方、およびWindowsとSolarisの両方で見られます。IntelPro1000デュアルポートネットワークカードを搭載したDell1950サーバーでテストしています。マイクロベンチマークは、特にJavaでは難しいですが、これはJITやGCに関連しているとは思われません。

テストに使用しているJavaコードとコマンドラインは次の場所にあります：http ：//www.moneyandsoftware.com/2009/09/18/multicast-send-performance/