WCF发现返回硬编码的URL

Question

宏伟的设计如下:

1. 某些应用程序作为Windows服务安装
2. 网络上可能有几个这样的
3. 它们中的每一个都暴露了一些网络接口(将其视为"远程控制"或"配置" - 这种事情)
4. 然后有另一个应用程序充当该接口的客户端(使用相同的类比 - "远程控制器"或"配置工具")
5. 后者的目的是在网络上嗅出前者的所有实例,将它们作为列表显示给用户并允许用户使用暴露的接口在不同的地方戳它们(即"远程控制"或"配置")他们)
6. 为简单起见,我们假设每个人都在同一个网络中 - 也就是说,每个人都可以听到彼此的UDP广播.

很简单,嗯？在过去的几天里,我曾经使用自己的基于UDP广播的发现机制来构建这类东西.

但是现在我觉得我很酷,很时髦,并且在Ad Hoc模式下使用常规的WCF Discovery.它的工作原理!谁能说出来？:-)

但并不完全.正如我之前在这里和那里所指出的,该发现从服务的配置返回硬编码的URL.也就是说,如果服务<baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses>在其配置文件中,那么这正是我将从发现客户端获得的 - 包括"localhost"部分.

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

所以问题是:如何让发现客户端给我可用的URL而不是localhost-ish垃圾？

为了节省每个人的时间,一些不起作用的想法:

1. 在部署时更改服务的配置文件,编码它的真实IP地址或计算机名称.
   不起作用,因为IP和机器名称都可能发生变化.
2. 使用当前IP或计算机名称从代码(至少部分)配置服务以构造URL.
   不行.机器名称没用,因为网络中可能没有dns.IP是没用的,因为计算机可能会在几个网络一次,因此,有几个IP地址(这不是假设,我们实际上做有这种情况).然后使用哪一个？

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

Answer 1

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

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