宏伟的设计如下:
-
某些应用程序作为Windows服务安装
-
网络上可能有其中一些
-
它们中的每一个都暴露了一些网络接口(把它想象成"remote control"或"configuration" - 那种事情)
-
然后有另一个应用程序充当该接口的客户端(使用相同的类比 - "remote controller"或"configuration tool")
-
后者的目的是在网络上嗅出前者的所有实例,将它们作为列表显示给用户并允许用户使用该暴露的接口在不同的地方戳它们(即"remote control"或"configure"它们)
-
为简单起见,让's assume that everybody is in the same network - that is, everybody can hear each other'的UDP广播 .
很简单,嗯?在过去的几天里,我曾经使用自己的基于UDP广播的发现机制来构建这类东西 .
但是现在我觉得我会变得很酷而且时髦,并且在Ad Hoc模式中使用groovy WCF Discovery . 它的工作原理!谁能说出来? :-)
但并不完全 . 正如我之前所述here和there,该发现从服务的配置返回硬编码的URL . 也就是说,如果服务中有 <baseAddresses><add baseAddress="net.tcp://localhost:1234/My/Service" /></baseAddresses>
正是我将从发现客户端获得的 - 包括"localhost"部分 .
不用说,如果我尝试使用该URL调用服务,结果并不令人兴奋 .
所以问题是:如何让发现客户端给我可用的URL而不是localhost-ish垃圾?
为了节省每个人的时间,一些不起作用的想法:
-
更改服务's config file at deployment time, encoding it'的真实IP地址或机器名称 .
不起作用,因为IP和机器名称都可能发生变化 . -
使用当前IP或计算机名称从代码(至少部分)配置服务以构造URL .
不行 . 机器名称没用,因为网络中可能没有dns . IP是没用的,因为计算机可能同时在多个网络上,因此有几个IP地址(这不是假设,我们实际上有这种情况) . 然后使用哪一个?
换句话说,我不需要调整服务,而是让发现客户端给我发现响应来自的地址 .
3 回答
您应该能够通过用通配符替换
localhost
来解决此问题:不要使用配置 .
以编程方式运行服务 .
以下是以编程方式添加 endpoints 的示例:Programmatic_Endpoint_Configuration
而这,为了比较:Self-hosting_and_base_addresses
除了通配符之外的另一个选项是使用本机的DNS可解析主机名instad .