WCF双工客户端最佳实践

Question

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

我担心的是，给定实例化的客户端对象，WCF是否能够判断哪个特定的客户端服务实例将接收回调参数？

有人能告诉我这是不是个好主意吗？如果不是，为什么不呢？

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

1. ，如果保留了上面的虚拟路径，那么如何丢弃它。我希望客户服务寿命短一些。(提出请求并收到答复)，当收到后，杀死它。在缩短客户端服务寿命方面，性能损失是多么糟糕，而不是将其池化并使其存活时间更长。

这样做是为了避免超时问题。当完成接收，发送，处置时，尽快。按照惯例-不能传递客户服务。如果您需要信息，创建一个新的，简单的-就像EF/L2等，

• 从内部的WCF服务本身，我如何杀死与客户端的会话。即。我不希望客户端结束会话-我知道我可以相应地装饰我的操作，但我希望服务在满足某些条件时以编程方式终止。

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

Answer 1

我认为最终双工服务只是微软另一个失败的架构。这是其中之一，这些东西看起来真的很好在纸上，但只是分崩离析的仔细研究。

有太多的弱点：

1)依赖会话，通过服务器建立客户端侦听器。这是会话信息存储在内存中。因此，服务器本身无法实现负载平衡。或者，如果它是负载平衡的，您需要打开ip关联，但是现在，如果其中一个服务器遭到轰炸，您就不能简单地添加另一个服务器，并期望所有这些会话自动迁移到新服务器。

2)对于每个位于路由器/防火墙/负载均衡器后面的客户端，需要创建一个具有特定端口的新端点。否则，路由器将无法正确地将回调消息路由到适当的客户端。另一种选择是有一个允许自定义编程将特定路径重定向到特定服务器的路由器。又是一项艰巨的任务。或者另一种方法是让回调的客户端托管自己的数据库并通过数据库共享数据--在某些情况下，许可费用不是问题.但是它在客户机上引入了很多复杂和繁重的内容，而且它将应用程序层和服务层混合在一起(在某些特殊情况下，这可能是可以接受的，但在庞大的设置成本之上)。

( 3)这一切基本上是说，复式实际上是没有用的。如果您需要回调，那么您将很好地在客户端设置wcf主机。它将更简单，更可伸缩。此外，客户机和服务器之间的耦合也较少。

对于可伸缩体系结构，最好的双工解决方案是最终不使用这种解决方案。

Answer 2

1. --它将取决于您需要的客户的时间有多短，以及它们将持续多长时间。如果您每次都特别需要一个新客户端，则不能选择池，但如果客户端一直在执行相同的任务，那么如果它们再次错误地重新创建同一个客户端，为什么不让一个客户池等待使用。实际上，在回调场景中，如果服务正在向客户端调用(实际上是调用客户端上的一个函数)传递信息，那么池将不是一种选择，服务现在是客户端，反之亦然。您可以使用使回调.Close()连接的服务，但是它将一直打开，直到GC能够释放它，根据我的经验，这可能比预期的时间更长。因此，简单地说，客户端应该负责关闭自身或断开连接(客户端是调用某物的客户端)，服务只应该返回答案或从客户端获取数据。
2. 在双工回调中，现在调用给客户端的服务将得到在重复通道工厂后面抽象的客户端地址。如果服务不能调用客户端--我不认为有什么可以做的--您必须确保您的客户端调用到服务的端口是开放的，以便接收回调。