Question

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

我担心的是，如果客户端对象被实例化，WCF是否能够告诉哪个特定的客户端服务实例将收到回调参数？

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

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

如果保留上面的虚拟路径，它怎么能被丢弃。我希望客户端服务的生命周期相当短。 IE发出请求并收到响应，完成接收后，将其杀死。在将客户端服务生命周期缩短而不是将其集中并使其保持更长时间时，性能损失有多严重。

这个想法是为了避免超时问题。完成接收，发送，尽快处理。按照惯例 - 无法传递客户服务。如果您需要信息，请创建一个新的，简单的 - 就像EF / L2S等。
从WCF服务本身内部，如何终止与客户端的会话。即。我不希望客户端结束会话 - 我知道我可以相应地修饰我的操作，但我希望服务在满足某些条件时以编程方式终止自身。
我可以粘贴端口并相应地转发以解决任何防火墙问题，但我担心的是客户端是否位于负载均衡器后面。服务如何知道要调用哪个特定服务器？

Answer 1

我认为最终Duplex服务只是微软另一个失败的架构。这是纸上看起来非常好的东西之一，但经过仔细研究就会崩溃。

有太多的弱点：

1）依赖会话来建立服务器的客户端监听器。这是会话信息存储在内存中。因此，服务器本身无法进行负载平衡。或者如果它是负载平衡的，你需要打开ip affinity，但现在如果其中一个服务器被轰炸，你就不能再添加另一个服务器并期望所有这些会话自动迁移到新服务器。

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

3）所有这些基本上都说双工几乎没用。如果你需要回电，那么你最好在客户端设置一个wcf主机。它将更简单，更具可扩展性。此外，客户端和服务器之间的耦合较少。

可扩展架构的最佳双工解决方案最终不使用。

Answer 2

这将取决于您需要多长时间的新客户以及他们将持续多久。如果您每次都特别需要一个新客户端，那么池不会是一个选项，但是如果客户端继续做同样的事情，为什么不让它们等待使用它们，如果它们出错，再次重新创建同一个客户端。
实际上在回调场景中，如果服务正在回调客户端（真正调用客户端上的函数）来传递信息，则服务现在是客户端，反之亦然。您可以使用正在进行回调的服务。关闭（）连接但是它将打开，直到GC可以处理它，根据我的经验可能需要比预期更长的时间。因此，简而言之，客户端应该负责（客户端是调用某个东西的客户端）关闭自己，或者断开连接，服务应该只回馈答案或从客户端获取数据。
在双工回调中，现在回叫客户端的服务将获取在duplexchannelfactory后面抽象的客户端的地址。如果服务无法回调客户端，我认为没有太多可以做的事情，你必须确保客户端正在调用该服务的端口是开放的，以接收我猜的回调。

WCF Duplex客户端的最佳实践

2 个答案: