.net 4 ws-discovery端点
我在 .NET 4.0 中使用 ws-discovery，它运行良好。我的一个问题是如何处理不起作用的服务。例如，假设我在服务器 A 和服务器 B 上都有 IService。假设服务器 A 上的此服务已损坏（通过停止应用程序池来模拟此情况）。您的客户仍然会找到 2 项服务，因此当您尝试使用该服务时，您无法保证它是正常工作的服务。
所以我的问题是，您是否通过循环端点来处理这个问题，如果第一个端点失败，请尝试下一个端点。或者有没有办法只检索搜索时“启动”的服务？或者我在某个地方错过了要点 - 很可能:-)
谢谢
I am using ws-discovery in .NET 4.0 and it is working well. One question I have is how to deal with services that are not working. For example, say I have IService on server A and server B. Let's say this service on server A is broken (mimic this by stopping Application Pool). Your client will still find 2 services, so when you attempt to use the service you cannot guarantee that it is the working one.
So my question is, do you deal with this by looping through the endpoints and if the first one fails try the next one. Or is there a way to retrieve only services that are "up" at the time of the search? Or am I missing the point somewhere - quite possibly :-)
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
本文似乎通过在运行时确定端点地址来涵盖您所讨论的内容。
http: //weblogs.asp.net/gsusx/archive/2009/02/13/using-ws-discovery-in-wcf-4-0.aspx
This article seems to cover what you are talking about by determining the endpoint address at runtime.
http://weblogs.asp.net/gsusx/archive/2009/02/13/using-ws-discovery-in-wcf-4-0.aspx
我发现这是 wcf 发现中的一个常见问题。当服务器位于两个网络上时，也会出现类似的问题。该发现将返回两个网卡地址，但当然，客户端只能通过这些网络之一到达服务器。
我一直使用的解决方法是向服务器添加“void Ping()”函数。然后在发现之后，客户端尝试在所有发现的端点上调用此“Ping()”函数。返回响应的是好的，其他的是坏的。
我最终更进一步，生成一个线程，偶尔继续调用这个“Ping()”函数。然后，当一个好的服务器消失时，该线程会从“好”uri 集合中删除该 uri。
我感受到你的痛苦。
I have found this to be a common problem in wcf discovery. A similar problem occurs when a server is sitting on two networks. The discovery will return both nic addresses, but of course, the client can only reach the server through one of these networks.
The workaround I have been using is to add a "void Ping()" function to the server. Then after discovery, the client tries to call this "Ping()" function on all discovered endpoints. The ones that return a response are good, others are bad.
I ended up taking this a step further and spawning a thread that continues to call this "Ping()" function occasionally. Then when a good server disappears, the thread removes that uri from a collection of 'good' uris.
I feel your pain.