[英]when to use duplex service?
Well, I know that in a duplex contract the service can send messages to the client, but I would like to know when that is really useful. 好吧,我知道在双工合同中服务可以向客户发送消息,但我想知道什么时候真的很有用。
I have a common application that send request to the service to get data from the a database, insert data... etc. Also, I need to store files about 40MB in the database, so I need a good performance. 我有一个通用的应用程序,发送请求到服务从数据库中获取数据,插入数据......等等。另外,我需要在数据库中存储大约40MB的文件,所以我需要一个良好的性能。 For this reason, I would like to use the net.tcp binding with transfer mode streamed, but the problem is that a net.tcp duplex service can't use the streamed transfer mode.
出于这个原因,我想使用net.tcp绑定传输模式流,但问题是net.tcp双工服务不能使用流传输模式。
So I think I have some options. 所以我觉得我有一些选择。
1.- study if I really need a duplex contract for this kind of application. 1.-研究我是否真的需要这种应用的双工合同。 Perhaps in a chat application, for example, it has more sense a duplex contract because the server perhaps need to notify to the client when a contact is connected... etc. But in a common client that access to a data base, is necessary a duple contract?
例如,在聊天应用程序中,它更具有双重合同的意义,因为服务器可能需要在联系人连接时通知客户端......等等。但是在访问数据库的公共客户端中,是必要的双重合同? what kind of operations would can need a duplex contract?
什么样的操作可能需要双工合同?
2.- Other option it's not to have a duplex contract, but implement a no duplex contract in the server and other single contract in the the client, so when a client connect to the service, the service receive the needed information to connect to the service of the client. 2.-其他选项它不是双工合同,而是在服务器中实现无双工合同和客户端中的其他单一合同,因此当客户端连接到服务时,服务会收到连接到服务的所需信息。客户服务。 But, is this a good way to avoid a duplex contract?
但是,这是避免双工合同的好方法吗?
3.- Really for my application I need tcp instead of a duplex HTTP that allows a streamed transfer mode? 3.-真的对我的应用程序我需要tcp而不是允许流传输模式的双工HTTP? What is the advantages of the tcp over the HTTP in terms of performance?
在性能方面,tcp优于HTTP的优势是什么?
Thanks. 谢谢。
You need duplex if you want to implement callback pattern. 如果要实现回调模式,则需要双工。 Callback means that client does not know when some event happens in server.
回调意味着客户端不知道服务器中何时发生某些事件。
If you do not know when event happens you have two options to implement: 如果您不知道事件何时发生,您有两种方法可以实现:
As you can see duplex/callback means that at some point server works as client (initiates communication) and this is a big game change. 你可以看到双工/回调意味着在某些时候服务器作为客户端工作(启动通信),这是一个重大的游戏变化。
WCF duplex communications may require special network configuration because in many cases network allows you to call external services (you work as client) but forbids external resources to call you (external service works as client). WCF双工通信可能需要特殊的网络配置,因为在许多情况下,网络允许您调用外部服务(您作为客户端工作)但禁止外部资源呼叫您(外部服务作为客户端)。 This is implemented for security purposes.
这是出于安全目的而实现的。
Returning to your questions: 回到你的问题:
Addressing each point: 解决每个问题:
1, 2. I think that for your scenario a duplex service is an overkill. 1,2。我认为对于您的场景,双工服务是一种过度杀伤力。 As you say yourself a duplex service is usually handy when both the client and service need to keep notifying each other on a constant basis, what you're doing, getting lots of data in/out of a database doesn't seem to be a good case for using duplex communication.
正如你所说,当客户端和服务需要不断地相互通知时,双工服务通常很方便,你正在做什么,从数据库中取出大量数据似乎不是一个使用双工通信的好例子。 Regarding
netTcpBinding
not allowing Streaming with duplex, you can just return a byte array ( byte[]
) instead of a stream. 关于
netTcpBinding
不允许使用双工进行流式处理,您只需返回一个字节数组( byte[]
)而不是流。 40 MB is a lot, but I don't think Streaming will necessarily have a significant performance gain over a duplex service which will return a byte array (up to you to test each setup and compare the results). 40 MB是很多,但我不认为流式传输必然会比双工服务有显着的性能提升,这将返回一个字节数组(由您来测试每个设置并比较结果)。 So you have a few options here, don't stream and return a byte array (you can do this with your duplex service) or you can just forget about making your service duplex since there doesn't seem to be a strong case for you to make it duplex and just return a Stream :
所以你在这里有几个选项,不要流式传输并返回一个字节数组(你可以用你的双工服务做到这一点)或者你可以忘记制作服务双工,因为似乎没有强大的案例给你使它成为双工并返回一个流 :
[OperationContract]
Stream RetrieveFile(long _fileId);
[OperationContract]
long SaveFile(Stream _stream);
3. netTcpBinding
has a considerable performance advantage over HTTP bindings, but it comes with a price, mostly because its TCP ports are sometimes blocked by internet firewalls, although you can use netTcpBinding
over the internet, it's not recommended . 3.
netTcpBinding
相对于HTTP绑定具有相当大的性能优势,但它带来了代价,主要是因为它的TCP端口有时被互联网防火墙阻止,尽管你可以通过互联网使用netTcpBinding
,但不建议这样做 。 Choosing a binding depends on what you're looking to do, if your clients are going to consume your service over the internet, then netTcpBinding
is not a good idea (blocked TCP ports, firewalls etc.), but if your clients are consuming the service in the same network (LAN) then netTcpBinding
is the most sensible choice. 选择绑定取决于您要查看的内容,如果您的客户要通过互联网使用您的服务,那么
netTcpBinding
不是一个好主意(阻止TCP端口,防火墙等),但如果您的客户正在使用在同一网络(LAN)中服务然后netTcpBinding
是最明智的选择。 wsDualHttpBinding
(doesn't support streaming :@) is a good choice if you want to stick to a duplex service (equivalent of PollingDuplexHttpBinding
in Silverlight), or any other HTTP based bindings if you let go of the idea of a duplex service. wsDualHttpBinding
(不支持流式传输:@)是一个不错的选择,如果你想坚持双工服务(相当于Silverlight中的PollingDuplexHttpBinding
),或任何其他基于HTTP的绑定,如果你放开双工服务的想法。
Some articles that may help you out, performance comparison of various WCF bindings: 一些可能会帮助你的文章,各种WCF绑定的性能比较:
http://blog.shutupandcode.net/?p=1085 http://blog.shutupandcode.net/?p=1085
http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html
And about Streaming large data with WCF over HTTP, according to the authors, both samples have been tested with up to 2GB of data: 据作者称,关于使用WCF通过HTTP流式传输大型数据,这两个样本都经过了高达2GB数据的测试:
http://garfoot.com/blog/2008/06/transferring-large-files-using-wcf/ http://garfoot.com/blog/2008/06/transferring-large-files-using-wcf/
http://www.codeproject.com/Articles/166763/WCF-Streaming-Upload-Download-Files-Over-HTTP http://www.codeproject.com/Articles/166763/WCF-Streaming-Upload-Download-Files-Over-HTTP
You shouldn't think that you must use netTcpBinding
or you must use Streamed transfer for your service, netTcpBinding
only becomes more performant than HTTP bindings after you enable throttling and configure some socket level properties. 您不应该认为必须使用
netTcpBinding
或者必须使用Streamed transfer作为服务, netTcpBinding
只有在启用限制和配置某些套接字级别属性后才会比HTTP绑定更高效。 And streaming 40 MB will not have significant performance gains over buffered transfer. 流式传输40 MB不会比缓冲传输带来显着的性能提升。 So you have a lot of options and a lot of trade-offs to make.
所以你有很多选择和许多权衡取舍。 There is no black and white and right or wrong, it's about how you customise your service to suit your needs best, most solutions will work.
没有黑白和正确或错误,它是关于如何定制您的服务以最好地满足您的需求,大多数解决方案将工作。 Your scenrio is a very common one and there are lots of stuff online about large data transfer in WCF, do more research ;)
你的场景非常常见,网上有很多关于WCF大数据传输的内容,做更多的研究;)
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.