为WCF双工客户端最佳实践

问题描述

我不能否认双工异步调用的性能优势，但对有些事情让我感到警惕。

我担心的是，鉴于实例化的客户对象，将WCF能够判断哪些特定的客户服务实例将收到回调参数？

谁能告诉我，如果这是一个好主意？如果不是，为什么不？

 新DuplexChannelFactory＆LT; IServerWithCallback＆GT;（
   新ClientService（），
   新NetTcpBinding的（）
   新的EndpointAddress（的net.tcp：//本地主机：1234 /+ Guid.NewGuid（）））
 

1. 如果上面的虚拟路径是保留它如何能够被丢弃。我希望客户端使用寿命是相当短。 IE浏览器发出请求和接收响应，并完成在接收时，杀死它。如何坏的是使客户机使用寿命短，而不是集中，并保持它活得更长。

   的性能损失

   我们的想法是，以避免超时问题。当完成接收，发送，尽快处置。按照惯例 - 无法通过周围的客户服务。如果你需要的信息，创建一个新的，简单的 - 就像EF / L2S等




2. 从WCF服务本身，我怎么杀与客户端的会话中。 IE浏览器。我不希望客户端结束会话 - 我知道我可以相应地装点我的操作，但我想要的服务时满足某些条件​​以编程方式终止本身。




3. 我可以加贴端口，并相应地转发到解决任何防火墙的问题，但我很担心的是，如果客户端是坐负载平衡器后面。服务如何知道调用哪个特定的服务器？

解决方案

我觉得到底双工服务仅仅是另一名来自微软未能架构。这是看起来真不错在纸面上的东西之一，但只是分崩离析经仔细检查。

有太多的弱点：

1）在会话依赖于由服务器建立客户端监听器。这是会话信息被存储在存储器中。因此，服务器本身不能被负载平衡。或者，如果它被负载均衡，你需要打开IP亲和力，但现在如果其中一台服务器轰击你不能简单地添加一个又一个，并期望所有这些会话自动地迁移到新的服务器。

2）为每一个客户坐在一个路由器/防火墙/负载均衡器后面，需要创建与特定端口新的结束点。否则路由器将不能够正确地路由回调消息发送到相应的客户端。另一种方法是有一个路由器，允许自定义编程为特定的路径重定向到特定的服务器。再一个很高的要求。或者另一种方式是与回调通过数据库＆LT举办自己的数据库和共享数据客户端; - 在某些情况下许可费不是问题，可能工作...但它引入了很多复杂和过于繁琐的在客户端上加上它混合的应用和服务层一起（其可能在一些特殊情况可以接受的，但不是在庞大的设置成本的顶部）

3）所有这一切基本上说，双工几乎是无用的。如果您需要再打那么你会做得很好设置在客户端的WCF主机。这将是更简单，更具扩展性。再加上有客户端和服务器之间的耦合少

有关可扩展架构的最佳解决方案复式在不使用一个结束。

I can't deny the performance benefit of a duplex async call, but some things about makes me feel wary.

My concern is that given a client object instantiated, will WCF be able to tell which particular client service instance will receive the callback argument?

Can anyone tell me if this is a good idea? If not why not?

new DuplexChannelFactory<IServerWithCallback>(
   new ClientService(),
   new NetTcpBinding(),
   new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid()))

1. If the virtual path above is reserved how can it be discarded. I want the client service lifetime to be fairly short. IE make a request and receive a response and when done receiving, kill it. How bad is the performance penalty in making the client service lifetime short as opposed to pooling it and keeping it alive longer.

   The idea is to avoid timeout issue. When done receiving, sending, dispose ASAP. By convention - can't pass the client services around. If you need info, create a new one, simple - just like EF/L2S etc.

2. From inside the WCF service itself, how do I kill the session with the client. ie. I don't want the client ending the session - I know I can decorate my operation accordingly, but I want the service to terminate itself programmatically when certain conditions are met.

3. I can affix the port and forward accordingly to resolve any firewall issue, but what I'm worried about is if the client were to sit behind a load-balancer. How would the service know which particular server to call?

解决方案

I think in the end Duplex services is simply another failed architecture from Microsoft. This is one of those things that looked really good on paper but just falls apart upon closer examination.

There are too many weaknesses:

1) Reliance on session to establish client listener by the server. This is session information is stored in memory. Hence the server itself cannot be load balanced. Or if it were load balanced you need to turn ip affinity on, but now if one of the servers is bombarded you can't simply add another one and expect all these sessions to automagically migrate over to the new server.

2) For each client sitting behind a router/firewall/loadbalancer, a new end point with specific port needs to be created. Otherwise the router will not be able to properly route the callback messages to the appropriate client. An alternative is to have a router that allows custom programming to redirect specific path to a particular server. Again a tall order. Or another way is for the client with the callback to host its own database and share data via a database <-- Might work in some situation where licensing fees is not an issue... but it introduces a lot of complexity and so onerous on the client plus it mixes the application and services layer together (which might be acceptable in some exceptional situation, but not on top of the huge setup cost)

3) All this basically says that duplex is practically useless. If you need call back then you will do well to setup a wcf host on the client end. It will be simpler and much more scalable. Plus there is less coupling between client and server.

The best duplex solution for scalable architecture is in the end not using one.

这篇关于为WCF双工客户端最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！