What is the advantage of WSDualHttpBinding in WCF?

Question

So far, no one can really offer any benefit of using dual channel over a client polling system except for the immediate notification you can get from the dual channel. Every other point says if you dont need immediate notice the dual binding provides negative value - anyone disagree with this?

How much benefit would there be to using WSDualHttpBinding with IIS hosted service vs. a client poll that calls the WCF service, assuming in the latter the service cached the data in question?

This scenerio would be for a notify type of service where the clients need to be notified by the service when an event occurs.

Specifically, what advantages would WSDualHttpBinding provide over polling? ie: Less network traffic, faster to design, easier to maintain, more control ???

From what i understand, WSDualHttpBinding is less scalable than client polling, so why use it at all? Edit: As Matt supplied, time critical can be one reason for the duplex binding.

Here is what i have so far:

WSDualHttpBinding

adv: can get immediate response w/o waiting on polling timer

dis: less scalable than WsHttpBinding

dis: less firewall friendly

dis: slower than WSHttpBinding

I'll add to this based on comments, please let me know if i state anything incorrectly.

thanks for you input :-)

Answer 1

There is a wealth of information in this SO thread. Basically, polling has the disadvantage that your client is only as up-to-date as its last poll, so for time-critical information you need to increase the frequency of polling. Each poll takes up network resources and creates overhead on the client. Solutions like long polling and WSDualHttpBinding are workarounds for that problem. WSDualHttpBinding has the disadvantage that the client must expose an endpoint to the server (which creates problems in firewalled environments). BOSH/XMPP or another form of long polling is another alternative.

Answer 2

WSDualHttpBinding was created for a reason. WCF provided support for service 'callbacks' - methods on the client that were notified whenever service execution completed. Unfortunately, HTTP - being a one way channel - would not allow for callbacks (by contrast, the TCPBinding allows it since TCP is a full duplex channel). To get around HTTP's one-way nature, the DualHttpBinding was invented - two simultaneously open HTTP connections - one for the service request - and one for the callback. It is not a question of scalability - but of need. If you want to use callbacks (and callbacks are great especially if your service is going to be a time consuming (long running) service), WSDualHttpBinding may be your best option. Polling is possibly the worst for reasons already pointed out - each poll takes up network resources etc.