when to use duplex service?

Question

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. 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.

So I think I have some options.

1.- study if I really need a duplex contract for this kind of application. 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. 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? What is the advantages of the tcp over the HTTP in terms of performance?

Thanks.

Solution 1

Addressing each point:

1, 2. I think that for your scenario a duplex service is an overkill. 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. 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). 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. 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. 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.

Some articles that may help you out, performance comparison of various WCF bindings:

http://blog.shutupandcode.net/?p=1085

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:

http://garfoot.com/blog/2008/06/transferring-large-files-using-wcf/

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. And streaming 40 MB will not have significant performance gains over buffered transfer. 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 ;)

Solution 2

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:

1. Polling - send requests every X minutes to check if event happened. Server should either return event details (if it happened) or return flag saying that you need to continue calling. Server also can return recommended timeout in advanced scenarios.
2. Callback - client sends some form of description what server should do if event happened. This may be pointer to function in C, delegate in .NET or endpoint schema in WCF. Server remembers that info and makes call from their side when time came.

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). This is implemented for security purposes.

Returning to your questions:

1. You do not need duplex if you only need to download big amount of data. You may need it if you want to catch updates that happened in server and notify clients. Duplex should work for Chat because in chat there are many scenarios when client needs to be notified with changes introduced by others.
2. What you described is hand-made variant of duplex channel. You should use proved and tested duplex implementation made by MS If you want server to call your method. Otherwise your option is polling.
3. You are right, you need tcp + streamed transfer mode to deal with big amount of data. TCP uses binary serialization which is more compact comparing to text serialization + with TCP you do not need to send any HTTP headers or SOAP envelops. Disable security if you do not need it. It has a big performance impact.

Comments

[Álvaro García]

Well, my actual needs are about 40MB files, but in the future it's probably that I need to use larger files, perhaps 500-1000MB. Also I don't understand why the limitation of the duplex contract and streaming, in a chat application, today is common to send file between clients and can be large files. Why to choose between a good transfer (streaming) or a duplex application?

[Rich]

My guess is the back and forth communication doesn't play well with the notion of a large continuous stream of data. There is also no reason why, and I imagine this is the case, that the chat itself is duplex while file communication is done via a separate service with different bindings. The chat server can even send a notice thru the duplex channel "hey, there's a file for you to download, go get it via the data channel"

[Mohammad Sepahvand]

The limitation of duplex+streaming will definitely have some technical reasoning behind it. In a chat applicaion you can have a duplex service and send your files as a byte[], I've actually done this before and it worked well for files of up to 100MB. In your case I don't think you even need a callback. Have a look at the 2 samples of large file transfer, apparently both have been tested for up to 2GB, and glancing at the code, it doesn't seem too difficult.