How to implement publish/subscribe communication over the internet_问答_开发者

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 WSDualHttpBind开发者_如何学Pythoning, 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.

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.

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.

Internet Communication Engine (ICE) offers IceStorm, a publish/subscribe service.

Its open source, and if you download the installation there is a sample Visual Studio project that demonstrates how to implement publish/subscribe (check out the "demos" .zip file and the "IceStorm" directory with the clock demo).

ICE will do all the heavy lifting for you, the learning curve is remarkably short, primarily because the documentation is massive, approachable and well written.

I strongly recommend you DDS (data distribution service from OMG) over the internet http://www.omg.org/news/meetings/workshops/Real-time_WS_Final_Presentations_2008/Session%203/03-02_Bertocci_et_al.pdf

From OMG, that's all I gotta say. Yes, I know you may think OMG is over. I don't, and as a government counselor I really push for standards. Keep in mind that besides the liberal ideology and crises, governments are still a huge customers and inter-operation is a must.

NServiceBus? Right, ok, that's fine, but ain't too complex to start right now? Learning curve is too ... steep? I guess is not but, any easier one?

ICE is a good choice. guys from CORBA world trying to make things better. Don't doubt it, use it, try it! Just a feeling: even with the storm service you might feel you are still in the request/reply world ... but is that a con?

But if you rather prefer a commercial but open solution, think about publish subscribe using protocol buffers (search Google protocol buffers) ... just a first approach http://protocolbus.casessite.org . This is my owm work ... sorry it's just an initial project but I'm working with a central broker distribution as an alternative transport (default is multicast but broadcast and udp is also available). Open source, so be free ...