Wcf 何时使用双工服务？

嗯，我知道在双工合同中，服务可以向客户端发送消息，但我想知道这什么时候真的有用

我有一个通用的应用程序，它向服务发送请求，从数据库中获取数据，插入数据。。。还有，我需要在数据库中存储大约40MB的文件，所以我需要一个好的性能。因此，我希望使用传输模式为流传输的net.tcp绑定，但问题是net.tcp双工服务不能使用流传输模式

所以我想我有一些选择

1.-研究我是否真的需要这种应用的双重合同。例如，可能在聊天应用程序中，它更适合于双工合同，因为服务器可能需要在联系人连接时通知客户端。。。但在访问数据库的普通客户机中，是否需要双重合同？什么样的操作需要双重合同

2.-其他选项不具有双工合约，而是在服务器中实现无双工合约，在客户端中实现其他单一合约，因此当客户端连接到服务时，服务接收连接到客户端服务所需的信息。但是，这是避免双重合同的好方法吗

3.-对于我的应用程序，我真的需要tcp而不是允许流传输模式的双工HTTP吗？与HTTP相比，tcp在性能方面有哪些优势

谢谢。

针对每一点：

1、2。我认为在您的场景中，双工服务是一种过度使用。正如您自己所说，当客户端和服务都需要不断地相互通知时，双工服务通常很方便，您正在做的事情，从数据库中获取大量数据似乎不是使用双工通信的好例子。关于

netTcpBinding

不允许双工流，您可以只返回字节数组（

byte[]

）而不是流。40 MB是很多，但我不认为流式传输一定会比双工服务有显著的性能提升，双工服务将返回字节数组（由您测试每个设置并比较结果）。因此，您在这里有几个选项，不要流式传输并返回字节数组（您可以使用双工服务执行此操作），或者您可以忘记使您的服务双工，因为似乎没有足够的理由使其双工，只需返回一个：

3.

netTcpBinding

与HTTP绑定相比具有相当大的性能优势，但它也有价格优势，主要是因为它的TCP端口有时会被internet防火墙阻止，尽管您可以在internet上使用

netTcpBinding

，但事实并非如此。选择绑定取决于您希望做什么，如果您的客户将通过internet使用您的服务，那么

netTcpBinding

不是一个好主意（阻止TCP端口、防火墙等），但是如果您的客户正在同一网络（LAN）中使用服务，那么

netTcpBinding

是最明智的选择

wsDualHttpBinding

（不支持流式传输：@）是一个不错的选择，如果您想坚持使用双工服务（相当于Silverlight中的

PollingDuplexHttpBinding

），或者放弃双工服务的想法，任何其他基于HTTP的绑定

一些文章可能会帮助您解决各种WCF绑定的性能比较问题：

关于使用WCF通过HTTP传输大数据，根据作者的说法，这两个样本都使用高达2GB的数据进行了测试：

---

您不应该认为您必须使用

netTcpBinding

或者您必须为您的服务使用流式传输，

netTcpBinding

只有在启用限制和配置某些套接字级别属性后才会比HTTP绑定更具性能。与缓冲传输相比，流式传输40MB不会有显著的性能提升。所以你有很多选择和权衡。没有黑白之分，没有对错之分，关键在于你如何定制你的服务以满足你的需求，大多数解决方案都会奏效。你的场景非常常见，网上有很多关于WCF中大数据传输的东西，请多做研究；）

如果要实现回调模式，则需要双工。回调意味着客户机不知道服务器中何时发生某些事件

如果您不知道事件何时发生，则有两个选项可供实施：

轮询-每X分钟发送一次请求，以检查事件是否发生。服务器应该返回事件详细信息（如果发生）或返回标志，表明您需要继续调用。在高级方案中，服务器还可以返回建议的超时

回调-客户端发送某种形式的描述，说明在事件发生时服务器应该做什么。这可能是指向C中的函数、.NET中的委托或WCF中的端点架构的指针。服务器会记住这些信息，并在时间到来时从他们身边打电话 正如您所看到的，双工/回调意味着服务器在某一点上充当客户机（启动通信），这是一个巨大的变化

WCF双工通信可能需要特殊的网络配置，因为在许多情况下，网络允许您呼叫外部服务（您作为客户机工作），但禁止外部资源呼叫您（外部服务作为客户机工作）。这是出于安全目的而实现的

回到你的问题：

如果只需要下载大量数据，则不需要双工。若要捕获服务器中发生的更新并通知客户端，可能需要它。双工应该适用于聊天室，因为在聊天室中有许多情况下，客户机需要通知其他人引入的更改

您所描述的是手工制作的双工信道变体。您应该使用经过验证和测试的双工工具

[OperationContract]
Stream RetrieveFile(long _fileId);
[OperationContract]
long SaveFile(Stream _stream);