問題タブ [discovery]

他の人のソース コードを読んだ場合、そのコードにどのようにアプローチしますか? どのようなパターンを探していますか (データ型、ループ、制御フローの使用など)? 他の人のコードを飽きずにどれくらい読めますか? これまでに発見した最もエキサイティングなパターンは何ですか?

特定のネットワーク インターフェイスが背後にある NAT のタイプ (フルコーン、制限付きコーン、ポート制限付きコーン、対称) を発見したいと考えています。

さまざまなツール ( http://freshmeat.net/projects/jstun/、http://code.google.com/p/boogu/ ) をテストしましたが、同じインターフェイスに対して異なる結果が報告されています。

Python（または他の言語、他に何も利用できない場合はJavaが2番目の選択肢）で決定的な答えを探しています。

私はUDDIとWs-Discoveryの違いを知っています（サービスとブロードキャストを検索する場所をよく知っています）。しかし、私の質問は次のとおりです。WCF で Web サービスを検出する最も簡単な方法は何ですか? 最も簡単に言えば、WCF に既に実装されていて、今すぐ使用できるものを意味します。UDDI または Ws-Discovery 用の WCF の組み込み実装は見たことがありません。

WCF でこれら 2 つのプロトコルについて共有できるリンクや経験はありますか?

アップデート

現在、.NET 4.0 での WS-discovery を待つか、WCF が提供する Peer to Peer バインディングを使用して独自の Discovery バインディングを作成するという 3 つの解決策について考えています。このようにして、リクエストをブロードキャストできます。または、eed3si9n のリンクによって提供される実装を使用します。

あとで実装を簡単に変更するためにゲートウェイインターフェースをやろうと思います。

私はディスククローラーを作成しています。ユーザーが既存のパスを指定しない場合、プログラムは使用可能なすべてのディスクを検索する必要があります。誰かがそれが可能であり、それがJavaからそれを行う方法であるかどうかを知っていますか？

私は実行可能な jar を実行しており、実行時にどちらを実行するかを決定できるように、jar 内のクラスのリストを見つけたいと考えています。jarファイルの名前がわからないため、解凍できない可能性があります

概要:サーバーとクライアントをセットアップしました。どちらも 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 とマルチキャストは私にとってかなり新しいトピックなので、どちらが好ましいアプローチで、どちらがネットワーク負荷を軽減するかを知りたいと思っています。

別の質問で、似たようなことを尋ねましたが、アルゴリズムをそこに投稿して、いくつかの回答を無効にするだけでした。ここで再質問します。

私がアルゴリズムを「発明」した場合、それがすでに公開されている/特許を取得しているかどうかを確認する最善の方法は何ですか?

あなたの考えを聞かせてください...

現在、UDDI を理解しようとしており、照会 API を使用していくつかの例を実行したいと考えていますが、SOAP メッセージで照会できる公開レジストリーが見つかりません。

IBM、Microsoft、および SAP は、数年前にパブリック UDDI サーバーをホストしていましたが、それは廃止されました。

xmethodsには公開されている Web サービスのリストが含まれていることは知っていますが、UDDI を使用した Web サービスの検出のみに集中したいと思います (後でサービスを実際に呼び出すことはありません)。

利用可能なパブリック UDDI レジストリを知っている人はいますか?