壮大なデザインは次のとおりです。
- Windowsサービスとしてインストールされる特定のアプリケーションがあります
- ネットワーク上にこれらのいくつかがあるかもしれません
- それらのそれぞれは、ネットワークへのいくつかのインターフェースを公開します（「リモート制御」または「構成」と考えてください-そのようなもの）
- 次に、そのインターフェイスのクライアントとして機能する別のアプリケーションがあります（同じアナロジーを使用-「リモートコントローラー」または「構成ツール」）
- 後者の目的は、ネットワーク上の前者のすべてのインスタンスをスニッフィングし、それらをリストとしてユーザーに表示し、ユーザーがその公開されたインターフェイス（つまり、「リモートコントロール」または「構成」）を使用してさまざまな場所でそれらを突くことができるようにすることです。彼ら）
- 簡単にするために、全員が同じネットワーク内にいると仮定します。つまり、全員が互いのUDPブロードキャストを聞くことができます。
かなり簡単ですよね？私は昔、ロールマイオウンのUDPブロードキャストベースの検出メカニズムを使用して、この種のものを数十個作成していました。
しかし今、私はクールでヒップになり、アドホックモードでグルーヴィーなWCFディスカバリーを使用すると思いました。そしてそれは動作します！誰が言うことができますか？:-)
しかし、完全ではありません。私の前であちこちで述べたように、ディスカバリーはサービスの構成からハードコードされたURLを返します。つまり、サービス<baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses>の構成ファイルにある場合、それはまさに私がディスカバリークライアントから取得しようとしているものです-「localhost」の部分を含みます。
言うまでもなく、そのURLを使用してサービスを呼び出そうとすると、スリル満点の結果にはなりません。
だから問題は、ディスカバリークライアントにローカルホストのようなゴミの代わりに使用可能なURLを与えるにはどうすればよいですか？
みんなの時間を節約するために、うまくいかないいくつかの考え：
- 展開時にサービスの構成ファイルを変更し、実際のIPアドレスまたはマシン名をエンコードします。
IPとマシン名の両方が変更される可能性があるため、機能しません。 - 現在のIPまたはマシン名を使用してURLを作成し、コードから（少なくとも部分的に）サービスを構成します。
動作しません。ネットワークにDNSがない可能性があるため、マシン名は役に立ちません。コンピュータが一度に複数のネットワーク上にあり、したがって複数のIPアドレスを持っている可能性があるため、IPは役に立ちません（これは架空のものではなく、実際にこの状況にあります）。どちらを使用しますか？
つまり、サービスを微調整する必要はなく、検出クライアントに検出応答の送信元のアドレスを提供させる必要があります。