How to establish 2-way communication between a web server and a site server?

I am planning a SaaS system, to be written in C#, ASP.NET using WCF that has two separate components:

1. On a static IP web server in the cloud will be a web app, common to all clients.
2. Inside each client's office will be another app, installed on a server with IIS.

The site app will obviously be able to connect to the web services published on the web site. But here's the rub - I also want the web app to be able to initiate a connection to the site app... and the on-site server may not necessarily have a static IP. I can't control this, because we may have hundreds of clients at some point in the future, and we cannot limit our saleability by insisting that the customer has a server开发者_JAVA技巧 with fixed IP.

So, how to do this?

I could have the site apps "checking in" with the web every minute or so, to give the web app the possibility of responding with a "while you're here, please do x,y,z..." but that seems very inelegant. Also, if we're talking about hundreds of clients, I don't want to be bombarding my web server with all these "hi there!" messages if they're not actually required.

Is there a better way?

WCF? Here we go:

• Use a message based approach (exchange message, no stateful method calls).
• Clients connect to the server. Establish a HTTP-based TWO WAY CONNECTION. This way the server can call back to connected clients. This is standard WCF stuff and works well through NAT with version 4 of the .NET framework.

Voila. In case of a disconnect the client can re-connect, re-identify himself and gets the pending messages.

IIRC "push communication" is done by letting the client do a HTTP Request with an indefinate timeout. Then the server responds when he has something to say. After the respons the client immediately makes a new request.

It works out the same way like the server is making the connection and takes far less resources than polling.

1. Dynamic DNS is one possibility, but depends on your clients/customers.
2. If the site app is created by you, it only has to contact the web server when its address has changed (or when the site server/web app is restarted). Still, a keep-alive heart beat of, say, every 30 min. to 1 hour isn't a bad idea.

Edit: I think SNMP services may provide the answer but I'm not a networking expert. You'll have to do some digging or ask a separate question on stackoverflow.

What would you say about Comet technology?

Sounds like you'll definitely need some sort of registry on the server, then it could attempt to call out to the client apps if it needs work doing.

Generally it is client apps that check in with the server every X seconds - this is how Selenium grid works anyway. With a central hub with which clients register. When the hub receives a request to run some tests it passes the jobs out to the clients to perform.

You may not need the "checking in". The server could just attempt to call out to a registered client app until it finds one that is available.This way only the server would need a static address (could use a DNS name instead of an IP to make it more robust).

Also have a look at XMPP PubSub. This could be a more robust and standardised way to handle this.

In the end I decided to go with NetTcpBinding, for reasons best given by @Allon Guralnek here. It's worth clicking through and reading what he has to say...