c# - WCF Discovery 返回硬编码的 URL

Question

总体设计如下:

1. 某些应用程序作为 Windows 服务安装
2. 网络上可能有几个这样的
3. 它们中的每一个都向网络公开一些接口(interface)(将其视为“远程控制”或“配置”之类的东西)
4. 然后有另一个应用程序充当该接口(interface)的客户端(使用相同的类比——“远程 Controller ”或“配置工具”)
5. 后者的目标是嗅出网络上前者的所有实例，将它们作为列表显示给用户，并允许用户使用公开的界面(即“远程控制”或“配置”它们)
6. 为了简单起见，我们假设每个人都在同一个网络中 - 也就是说，每个人都可以听到彼此的 UDP 广播。

很简单，是吗？在过去，我曾经使用我自己的基于 UDP 广播的发现机制来构建这种东西。

但现在我想我会很酷很时髦，并在 Ad Hoc 模式下使用 groovy WCF Discovery。它有效!谁能说得清？ :-)

但不完全是。正如我之前提到的 here 和 there ，发现从服务的配置中返回硬编码的 URL。也就是说，如果服务的配置文件中有 <baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses>，那么这正是我将从发现客户端获得的内容 - 包括“本地主机”部分。

不用说，如果我尝试使用该 URL 调用该服务，结果并不令人兴奋。

所以问题是:如何让发现客户端为我提供可用的 URL，而不是像本地主机一样的垃圾？

为了节省大家的时间，一些行不通的想法:

1. 在部署时更改服务的配置文件，将其编码为真实的 IP 地址或机器名称。
   不起作用，因为 IP 和机器名称都可能更改。
2. 通过代码配置服务(至少部分配置)，使用当前 IP 或机器名称构建 URL。
   不起作用。机器名是无用的，因为网络中可能没有 dns。 IP 是没有用的，因为计算机可能同时在几个网络上，因此，有多个 IP 地址(这不是假设，我们实际上确实有这种情况)。那该用哪一个呢？

换句话说，我不需要调整服务，而是让发现客户端给我发现响应来自的地址。

Answer 1

您应该能够通过将 localhost 替换为通配符来解决此问题:

<baseAddresses><add baseAddress="net.tcp://*:1234/My/Service" /></baseAddresses>