嗯,我知道在双工合同中,服务可以向客户发送消息,但我想知道什么时候真的很有用。
我有一个常见的应用程序,它向服务发送请求以从数据库获取数据,插入数据......等等。另外,我需要在数据库中存储大约40MB的文件,所以我需要一个良好的性能。出于这个原因,我想使用net.tcp绑定传输模式流,但问题是net.tcp双工服务无法使用流传输模式。
所以我认为我有一些选择。
1.-研究我是否真的需要这种应用的双工合同。例如,在聊天应用程序中,它更具有双重合同的意义,因为服务器可能需要在联系人连接时通知客户端......等等。但是在访问数据库的公共客户端中,是必要的双重合同?什么样的业务可能需要双工合同?
2.-其他选项不是拥有双工合同,而是在服务器中实现无双工合同以及客户端中的其他单一合同,因此当客户端连接到服务时,服务会收到所需的信息连接到客户端的服务。但是,这是避免双面合同的好方法吗?
3.-真的对我的应用程序我需要tcp而不是允许流传输模式的双工HTTP吗?在性能方面,tcp相对于HTTP有什么优势?
感谢。
答案 0 :(得分:7)
如果要实现回调模式,则需要双工。回调意味着客户端不知道服务器中何时发生某些事件。
如果您不知道事件何时发生,您有两种方法可以实施:
正如你所看到的,双工/回叫意味着在某些时候服务器作为客户端工作(启动通信),这是一个重大的游戏改变。
WCF双工通信可能需要特殊的网络配置,因为在许多情况下,网络允许您呼叫外部服务(您作为客户端工作)但禁止外部资源呼叫您(外部服务充当客户端)。这是出于安全目的而实现的。
回到你的问题:
答案 1 :(得分:5)
解决每个问题:
1,2。我认为对于您的方案,双工服务是一种过度杀伤力。正如你所说,当客户端和服务需要不断地相互通知时,双工服务通常很方便,你正在做什么,从数据库中取出大量数据似乎不是一个使用双工通信的好例子。关于netTcpBinding
不允许使用双工进行流式处理,您只需返回一个字节数组(byte[]
)而不是流。 40 MB是很多,但我不认为流式传输必然会比双工服务有显着的性能提升,这将返回一个字节数组(由您来测试每个设置并比较结果)。所以你在这里有几个选项,不要流式传输并返回一个字节数组(你可以用你的双工服务做到这一点)或者你可以忘记制作服务双工,因为似乎没有强大的案例给你使其成为双工并返回Stream:
[OperationContract]
Stream RetrieveFile(long _fileId);
[OperationContract]
long SaveFile(Stream _stream);
3。 netTcpBinding
相对于HTTP绑定具有相当大的性能优势,但它带来了代价,主要是因为它的TCP端口有时被Internet防火墙阻止,尽管您可以使用{ {1}}在互联网上,它不是recommended。选择绑定取决于您要查看的内容,如果您的客户要通过互联网使用您的服务,那么netTcpBinding
不是一个好主意(阻止的TCP端口,防火墙等),但如果您的客户端在同一网络(LAN)中使用该服务,然后netTcpBinding
是最明智的选择。 netTcpBinding
(不支持流式传输:@)是一个不错的选择,如果你想坚持双工服务(相当于Silverlight中的wsDualHttpBinding
),或任何其他基于HTTP的绑定,如果你放手双工服务的想法。
有些文章可以帮助您,各种WCF绑定的性能比较:
http://blog.shutupandcode.net/?p=1085
http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html
关于使用WCF通过HTTP流式传输大型数据,据作者称,两个样本都经过了高达2GB数据的测试:
http://garfoot.com/blog/2008/06/transferring-large-files-using-wcf/
http://www.codeproject.com/Articles/166763/WCF-Streaming-Upload-Download-Files-Over-HTTP
您不应该认为必须使用PollingDuplexHttpBinding
,或者您必须使用流式传输服务,netTcpBinding
只有在启用限制后才能比HTTP绑定更高效并配置一些套接字级属性。流式传输40 MB不会比缓冲传输带来显着的性能提升。所以你有很多选择和许多权衡取舍。没有黑白和正确或错误,它是关于如何定制您的服务以最好地满足您的需求,大多数解决方案将工作。你的场景很常见,网上有很多关于WCF大数据传输的东西,做更多的研究;)