It depends on what capabilities your service needs to expose, and what type of clients you need to support. Any of the HTTP-based bindings will work over the internet, its simply a question of the way the data is encoded.
A summary of the built-in bindings and what they support can be found here: http://msdn.microsoft.com/en-us/library/ms731092.aspx
But the most common are:
- BasicHttpBinding - This is a basic web service-style binding, usable by any SOAP client.
- WebHttpBinding - This allows your service to be used by non-SOAP HTTP clients
- WsHttpBinding - This allows your service to use extended service features like transactions and sessions.
- WsDualHttpBinding - This is required if your service needs a duplex channel, meaning your service needs to make callbacks up to the client.
Since you specifically asked about the dual binding:
If you are writing an application that needs to be able to make a callback from server into the client, then a dual binding is really your only option. Since you specifically mentioned chat, however, I don't think a dual-channel service is going to work very well.
The way the callbacks work in WCF is that your client makes a call to the service, using a dual channel, and must provide an implementation of the callback interface. The server can use this to make calls to the client for the duration of the service method call; the callback context is per-service-call, so once that call returns, it is no longer valid. In other words, your server cannot just asynchronously "call into" your client, it has to wait for the client to "poll" the server. And if you're going to do that, you don't really need the callback anymore.
Honestly, I don't think I would use WCF for an interactive bi-directional chat application, but I can think of two possible options to do so:
- Do the polling client option, using a simple BasicHttpBinding on the server and continuously ask for new messages.
- Set your client applications up to self-host a local WCF service, and provide the endpoint information to the server when you log in. This requires your clients to accept incoming connections, which gets messy (but if you can pull it off, I'd go for a NetTcpBinding here.)