Question

I’m planning on using a wsDualHttpBinding for a WCF service with callbacks. The clients will be a windows form application communicating to the service over the internet. Obviously I have no control over the firewall on the client side, so I’m wondering what is the proper way to set the ClientBaseAddress on the client side?

Right now in my intiial testing I’m running the service and client on the same pc and i am setting the binding as follows

Dim binding As System.ServiceModel.WSDualHttpBinding = Struct.Endpoint.Binding
binding.ClientBaseAddress = New Uri("http://localhost:6667")

But I have a feeling this won’t work when deploying over the internet because “localhost” won’t translate to the machine address (much less worrying about NAT translation) and that port might be blocked by the clients firewall.

What is the proper way to handle the base address for callbacks to a remote client?

some one tell me if i do not specify ClientBaseAddress then WCF infratructure creates a default client base address at port 80 which is used for the incoming connections from the service. Since port 80 is usually open to firewalls, things should just work.

so just tell me when win form wcf client apps will run then how can i open my custom port like “6667” and also guide me what library or what approach i should use as a result response should come from client side router
to pc and firewall will not block anything. please discuss this issue with real life scenario how people handle this kind of situation in real life. thanks

Answer 1

The proper way is to use TCP transport instead of HTTP transport. Duplex communication over HTTP requires two HTTP connections – one opened from client to server (that’s OK) and second opened from server to client. This can work only in scenarios where you have full control over both ends. There is simply too many complications which cannot be avoided just by guessing what address to use like:

• Local Windows or third party firewall has to be configured
• Permission for application to run – listening on HTTP is not allowed by default unless UAC is turned off or application is running as admin. You must allow listening on the port through netsh or httpcfg (windows XP and 2003) – that again requires admin permissions.
• Port can be already used by another application. In case of 80 it can be used by any local web server – for example IIS.
• Private networks and network devices – if your client machine is behind the NAT the port forwarding must be configured but what if you have two machines running your application on the same private network? You cannot forward from the same incoming port to two machines.

All these issues can be avoided mostly only when you have control over whole infrastructure. That is the reason why HTTP duplex communication is useful mostly for intranet scenarios and why for example Silverlight offers another implementation where the second connection is not created and Silverlight client instead polls server continuously to check if there is any callback available.

TCP transport requires only single connection from client to server because TCP protocol is natively duplex so the server can call back the client through the same connection. When you deploy a public service you usually have control over infrastructure on the server side so you can make necessary changes in configuration to make it work.

I think this also answers your previous question.