views:

52

answers:

2

I have a .Net service hosted on a server, and .Net clients connecting to this server over the internet.

I want to implement a publish subscribe model where clients can subscribe to events on the service and have data pushed to them as data becomes available. An alternative would be to have clients poll the server for data, however this will likely be too slow for what is required. Hence the need for a publish/subscribe type of communication.

I understand that the WCF binding WSDualHttpBinding does allow this, however it comes with a downside. According to "Programming WCF Services" author Juval Lowy,

...the WSDualHttpBinding is mostly unusable, since it is practically impossible to tunnel through various communication barriers separating the service from the client and the need to find a specific web-server machine makes this impractical.

I've interpretted this to mean (please correct me if I'm wrong) that to operate with WSDualHttpBinding, it is necessary for clients to open a port on their machines (along with any necessary router configuration) for the server to callback through. If this is the case using WSDualHttpBinding will not be an option for me. Using Windows Azure will also not be an option.

So the crux of my question is, how can I achieve a publish/subscribe/callback type of communication over the internet, without the need to open ports on the client machine? Open standards are ok but unnecessary as client and server are both .Net, Windows Azure is not an option.

+1  A: 

WSDualHttpBinding contains two channels one from client to server and second from server to client. The later one indeed requires firewall and NAT configuration. What about Net.Tcp? It uses only single channel and supports callbacks (duplex communication) over that channel initiated from client to server. You mentioned that both client and server will be .NET application so it should be possible with some firewall configuration on the server.

Ladislav Mrnka
Thanks I'll have a look into this option.
Simon
A: 

You mention most of the options in your post.

There are 3 options:

  • Client polls the server. Does not require open ports but too slow.
  • WSDualHttpBinding requires opening of ports
  • Azure Service Bus, would do it but not an option.

There is actually a way to do it. If you look at how Azure service bus works, it tricks the client into thinking that it is on an out going port, when really it being used to send messages to the client. You could try to implement this functionality.

Another thing you could try is nservicebus at http://nservicebus.com/, this is an open source .net service bus.

Shiraz Bhaiji