宏伟的设计如下：
- 某些应用程序作为 Windows 服务安装
- 网络上可能有几个
- 他们每个人都向网络公开了一些接口（将其视为“远程控制”或“配置” - 那种东西）
- 然后有另一个应用程序充当该接口的客户端（使用相同的类比 - “遥控器”或“配置工具”）
- 后者的目标是在网络上嗅出前者的所有实例，将它们作为列表显示给用户，并允许用户使用暴露的界面（即“远程控制”或“配置”）在不同的地方戳它们他们）
- 为简单起见，我们假设每个人都在同一个网络中——也就是说，每个人都可以听到彼此的 UDP 广播。
很简单，嗯？在过去，我曾经使用自己的基于 UDP 广播的发现机制来构建这种东西。
但现在我想我会很酷很时髦，并在 Ad Hoc 模式下使用 groovy WCF Discovery 。它有效！谁能告诉？:-)
但不完全是。正如我之前在这里和那里所指出的，发现从服务的配置中返回了硬编码的 URL。也就是说，如果服务<baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses>在它的配置文件中，那么这正是我将从发现客户端得到的——包括“localhost”部分。
不用说，如果我尝试使用该 URL 调用服务，结果并不令人兴奋。
所以问题是：我如何让发现客户端给我可用的 URL 而不是 localhost-ish 垃圾？
为了节省大家的时间，有几个想法是行不通的：
- 在部署时更改服务的配置文件，将其编码为真实 IP 地址或机器名称。
不起作用，因为 IP 和机器名称都可能更改。 - 从代码（至少部分）配置服务，使用当前 IP 或机器名称来构造 URL。
不工作。机器名无用，因为网络中可能没有 dns。IP 没用，因为计算机可能同时在多个网络上，因此有多个 IP 地址（这不是假设，我们确实有这种情况）。那该用哪一个呢？
换句话说，我不需要调整服务，而是让发现客户端给我发现响应来自的地址。