On the Internet, if you need fast,
secure server-to-server communication,
and you can specify which firewall
ports are open, NetTcpBinding can
prove very valuable.
a) Is text implying that with some other connection protocols, such as HTTP, we don't need to check for open firewall ports?
b) Why would NetTcpBinding only be useful for server-to-server communications, but not for client-to-server communications?
thank you
a) When you deploy to an enterprise, you usually don't have control over their external firewall. The setup of their firewall is made by network administrators following an enterprise wide policy. External firewalls almost always allow outgoing HTTP requests (otherwise you couldn't browse the web). Some corporate firewalls block outgoing TCP requests, which means you cannot use netTcpBinding. As an example, see this question for somebody trying to deal with that issue. If you KNOW that the firewall of every one of your customers will allow outgoing TCP, then NetTcpBinding is an appropriate choice.
b) Who says NetTcpBinding is only useful for server-to-server communications? You can deploy a client-server application into an enterprise, and providing the clients and the servers are all within the intranet, then NetTcpBinding is an appropriate choice of binding.
Related
I am publically distributing an application which can be installed on users PC. Client will periodically communicate with the server to send information from the client. Server have to acknowledge the successful receipt of the information. Occasionally, server will do an one way communication with the client. My question is what is the best/failproof/recommended way to do client-server communication when client is massively distributed? I am currently focusing on self-hosted service to do the communication. What precaution should i take if the clients ip address change frequently?
My suggestions are:
Use HTTP or HTTPS on default ports. By massively I understand you will have no control over the network restrictions, firewalls, NAT traversal, etc. Using HTTP(S) and initiating the connections from the clients with simple web requests will save you a lot of trouble.
Use polling at regular/smart intervals to solve your occasional server initiated data transfer. Clients running on workstations wont have a public IP address, let alone a fixed one.
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
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.
Is you're building a distributed architecture with various services, is it acceptable to have those services communicate via ssh port forwarding, so that to a client a service looks like it's being served on a local port?
The only person who can answer "is it acceptable" is you, or your client.
Is it wise? Probably not, because SSL with certificates at both ends will deliver the same capability with a much less troublesome intermediate layer, but that is an engineering decision you have to make.
We're using a duplex contract for one feature in our yet to be released enterprise level LOB application that utilizes a thick client built with WPF and a server built with WCF.
During development so far we've been using the net.tcp binding for best performance. Now that deployment is coming up and issues such as internet access through a web proxy come to light, net.tcp isn't suitable anymore.
I've started using wsHttp and wsDualHttp but have realised in the meantime that duplex connections through a web proxy (and with NAT traversal) isn't really possible.
Now I'm thinking: why can't I set up a tcp tunnel (using proprietry software that supports web proxies, using HTTP CONNECT) and get the best of both worlds, proxy support, speed and security?
It would seem this is a common requirement.
Your options are not expansive. Microsoft's Service Bus is probably your best bet, if it works for your needs. The other options are:
VPN: Pretty self-explanatory.
SSH: SSH has tunneling functionality built-in. If you only have a small number of connections, you might be able to use an off-the-shelf SSH client and server, but with a larger number of connections it's hard to ensure that they all stay connected reliably. Several companies make SSH components you might be able to build upon (they didn't work for our needs), but they are more oriented toward the remote-execution use of SSH than tunneling.
A DIY TCP tunnel, which is a big job. Not impossible, but a big job. And will require a tremendous amount of testing to make sure you've got it right.
As far as running WCF over a tunneled connection, if you go that route, you won't have any problems. All the bindings and features work-- callbacks, reliability, message security, transport security, transactions, all work just fine.
We have created a WCF using net.tcp with an anticipation that the service can work in a firewall that would accept only HTTP port. The client behind firewall can also access it.
Do we need to host the service on a static, public IP so that any client from any network can conect to it?
Ideally, we would like to host the service on a node behind a firewall (say on 192.168.0.199) so that a client on some other network could connect to it.
Please suggest.
Well, either you need to make the service publicly visible somehow - using a public IP, or by routing a publicly visible IP on your corporate firewall to your internal server. But yes - it needs to be publicly visible one way or another.
The other option would be to connect it to the Windows Azure Service Bus - in that case, you could keep it behind the firewall, and just establish a publicly visible IP "in the cloud" that will then route the traffic to your web server.
Marc
I may be off on this but WCF client should have no issues communicating with a WCF server behind a firewall. Even application - level firewalls are OK in this scenario, as long as you configure them to not inspect past layer 4. Do not authenticate or do anything with your traffic at the firewall - simply NAT it to an inside IP address and you should be ok.
Couple of notes: transport security might be a little better to this observer but both transport and message level security in WCF should work without problems through firewalls. If you need message streaming though, then you are stuck with transport level security.
If your firewall (or one of your firewalls) happens to be Microsoft ISA or TMG type device, you may find this helpful: http://www.run-corp.com/how-to-configure-wcf-application-on-microsoft-isa-tmg-firewall/.