C#学习教程：WCFDuplex客户端的最佳实践分享

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

有太多的弱点：

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

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

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

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

1. 这将取决于您需要多长时间的新客户以及他们将持续多久。 如果您每次都特别需要一个新客户端，那么池不会是一个选项，但是如果客户端继续做同样的事情，为什么不让它们等待使用它们，如果它们出错，再次重新创建同一个客户端。

2. 实际上在回调场景中，如果服务正在回调客户端（真正调用客户端上的函数）来传递信息，则服务现在是客户端，反之亦然。 您可以使用正在进行回调的服务。关闭（）连接但是它将打开，直到GC可以处理它，根据我的经验可能需要比预期更长的时间。 因此，简而言之，客户端应该负责（客户端是调用某些东西的客户端）来关闭自己，或者断开连接，服务应该只返回答案或从客户端获取数据。

3. 在双工回调中，现在回调给客户端的服务将获得在duplexchannelfactory后面抽象的客户端的地址。 如果服务无法回调客户端，我认为没有太多可以做的事情，你必须确保客户端正在调用该服务的端口是开放的，以接收我猜的回调。

   上述就是C#学习教程：WCF Duplex客户端的最佳实践分享的全部内容，如果对大家有所用处且需要了解更多关于C#学习教程，希望大家多多关注&＃8212;编程笔记