I am researching doing a two way communication app, not necessarily peer to peer. Looking at using wcf, I am curious as to the inner workings on all of this. A big concern for me is NAT / firewalling.
I need to have this work without portforwarding on the clients. I will port forward the server, thats fine. but the clients need to be able to connect to the server, and then communicate back and forth through this now open (NAT and Firewall) connection.
The duplex wcf examples I am stydying, all seem to use a client address announced to the server to use for callback. Presuming this is a local lan adress, that wont work for public connections. If its the public address, port forwarding will be needed?
Am I missing something? I want to make a connection, keep it open, and use it in a duplex fashion. Thereby, getting past NAT and firewall restrictions once the client "dials out".
Further more, I am not quite sure on precisely how NAT is implemented. If I "punch" out a connection to a wcf service on port 5555, and receive a reply back, does port 5555 from / to that wcf service address stay in the NAT table? If I were to issue further connections from the server wcf service, and "connect" to a wcf service running on the client, (connect to the client public ip), will the NAT table know its me, and forward the traffic on to the client that initially punched the hole?
My final implementation would be:
Remote client <-> server behind port forward <-> management app issuing commands to the server which relays them to the remote clients.
Am I barking up the wrong tree trying to use wcf? I started working on this using raw tcp a while ago, but picking up the project now again, I would like to go the wcf route to sort out all the overhead on rolling my own raw tcp communication.
Thanks for any insight provided.
EDIT: [PING-PONG] Hello Word?
With duplex services you can have independent communication between a server and clients.
Something to keep in mind about duplex services:
The duplex model does not automatically detect when a service or client closes its channel. So if a service unexpectedly terminates, by default the service will not be notified, or if a client unexpectedly terminates, the service will not be notified. Clients and services can implement their own protocol to notify each other if they so choose.
As far as the NAT/firewall settings preventing your services from working is indeed a good concern to have. However, your situation seems to fall in line with a typical two-way communication setup between client and server. I wouldn't suspect you having trouble getting things to work with a little bit of trial and error.
If I "punch" out a connection to a wcf service on port 5555, and receive a reply back, does port 5555 from / to that wcf service address stay in the NAT table? If I were to issue further connections from the server wcf service, and "connect" to a wcf service running on the client, (connect to the client public ip), will the NAT table know its me, and forward the traffic on to the client that initially punched the hole?
To my knowledge this is basically how NAT works. As long as the public IP of your server is accessible on port 5555 to both inbound/outbound traffic, you should be fine. You should maybe research or ask a question about this on Server Fault.
Am I barking up the wrong tree trying to use wcf? I started working on this using raw tcp a while ago, but picking up the project now again, I would like to go the wcf route to sort out all the overhead on rolling my own raw tcp communication.
I don't think you're barking up the wrong tree. It just depends on what you're trying to accomplish. WCF will do a lot of the heavy lifting for you and let you focus on the core of your application. However, if you're wanting to learn more about socket programming then rolling your own network API/library would be something to continue doing.
Related
I'm having difficulty finding help resources on this. I know how to use the TCPClient class to create a connection between one IP/Port/machine and another.
My doubt is how does that work when one machine wants to initiate a TCP connection to another machine where the destination machine is inside a different network. So the destination network may have hundreds of computers each with its own private ip and the network would have one public IP address. This would be using the TCPClient class or any other that is more appropriate.
I know we could use ports and then inside the network the port could be forwarded to the correct machine but I was looking for a solution like the one services like LogMeIn use. Basically I wanted to use port 80 always and then initiate the connection from the server to that particular machine or others on the same network when I needed.
I suppose, theoretically, I could create the connection first from inside that network, then on the server, save the details and close the connection and then in the near future, when I needed, I would re-open the connection.
So in my scenario, I would have many clients across multiple networks, each network might have multiple internal machines with a client installed. Then on the server I would initiate connection to these machines when needed. Within each network I would want to use port 80 for obvious reasons. The reason I want to initiate the connection from the server and not the client machines is simply to save resources, I couldn't cope with having opened connections until eventually I might need to communicate wit them.
Also, I have no control on the client networks besides them having my client installed.
Ideally, I wish to have c# info, possibly code and not network configuration.
I had this requirement at a previous company. We installed our client/server software (C# based) on numerous different networks with a mix of public/private IPs. I found two relatively simple ways to solve it. First, I want to say that without a public IP, its impossible to connect reliably (in my experience).
When I proposed the solution, I explained the problem to other developers/managers this way.
Your server, the machine with the public IP address [public to clients, but may still be an "internal address"], is like a house without any long distance calling. It can receive calls, but it can't make any calls. The clients are like houses with long distance service. Clients must call the server, because they have long distance. Once connected, any party can talk on the line.
From here you have two choices.
Client connects and never disconnects (this is what I implemented). On the server, I had an object that mapped the client object to the client connection so I could communicate any time with a client that was connected.
Server holds a queue of messages for the client. The client automatically connects on a fixed interval to see if there are any messages (maybe 5 minutes). There would be an option from the server to stay connected for a specific interval. Another vendor called this "fast talk".
There's a couple of approaches.
You could setup NAT - probably no good for your scenario.
You could make an outbound connection from your client.
You could "combine the above" by using STUN (see http://en.wikipedia.org/wiki/STUN) this is quite popular in VOIP for peer to peer scenarios.
The Windows Azure servicebus may have a solution for your problem; NetTcpRelayBinding in hybrid mode allows two comuters behind NAT to create a direct connection with each other. This might not solve your problem if you are money constrained as each connection has an associated cost.The simplest solution is probably to have the clients polling your server.
You may use SignalR, which has been developed for this kind of scenarios.
You must have a third party, though (a server which broadcasts messages from sender to other peers).
But the beauty of this technology is that it chooses the most appropriate way to push data to clients: Polling, long connections, sockets... etc.
This provides an abstraction layer which is quite comfortable.
It has been designed to interact with javascript clients, but may be used in full-C# clients as well.
You need a third server that acts as proxy between your machine and target machine that is behind a firewall.
That is how applications like LogMeIn work.
You can do this using SSH tunnels.
Please check https://serverfault.com/questions/285616/how-to-allow-remote-connections-from-non-localhost-clients-with-ssh-remote-port
The topic is about NAT traversal.
STUN is good choice to try to communicate with client behind NAT.
But if STUN don't work,you can use RELAY service to help to pass the message between your server and remote client.RELAY service is a public service that everyone can reach it.
So many programs in the past and even the present operate on a Server/Client basis. Examples include TeamSpeak, Ventrilo, Mumble, etc. These programs typically require going into the router and forwarding ports so that the computer running the server can get the messages from the clients which are sending connection requests to the server's router.
Is there anything in WCF these days that allow you to prevent that sort of thing? I have a chat/file transfer program and I would really prefer that users not have to know how to forward their ports.
What kind of options are there out there in the way of UPnP or Punchthrough? The notion of having to go through and forward all the specific ports that a program uses seems so outdated.
Have a look at WS-Discovery with WCF:
http://weblogs.asp.net/gsusx/archive/2009/02/13/using-ws-discovery-in-wcf-4-0.aspx
The discovery protocol negates a central, "server router" as you put it. It's uses UDP broadcast to notify clients of each other.
Note that the discovery protocol itself is just a stateless messaging protocol. It has no guarantees or state synchronization. If for example, Client A doesn't receive the broadcast message from Client B, then Client A wont know of Client B. The protocol overhead of maintaining this P2P states is complex and usually a single server to hold this state is the easiest approach.
This topic has been discussed million times before, but let me clarify my needs:
I need a single server which controls a system and includes the necessary functions. Furthermore, there will be "n" Clients which represents only the HI/GUI and call server side functions. The server itself should be able to send data back to the clients and call client-side functions too (like shutdown, exit and so on...)
I have heard about duplex services/contracts (http://msdn.microsoft.com/en-us/library/ms731064.aspx), but I'm not sure how far I'll come with that.
How would you handle this?
I recently made a proof of concept app that made both the server and the client host a WCF service each. The client connects to the server and then in a handshake call, gives the server the connection information to allow the server create a separate connection back to the client. It worked a treat with multiple clients on network links from local lan to 64k line on remote sites at the same time.
You could use WCF, and host the service on the server in IIS, in the application on the client and let the client register it's endpoint on the server.
I need to write an application that acts as a proxy between a client and a service. All I want to do is read the data that is traveling in both directions from client to service and vice versa. In essence I want this proxy to be able to be just plugged in without the need to reconfigure port settings in either the client or the service. Is this possible? Is there any specific library I could use in the C# .Net framework that will help?
EDIT: The service is on a remote machine.
EDIT: Example: Lets assume that the client is communicating to the service via port 1234 and the service is communicating to the client via port 5678. I want the application to listen and read the data traveling through these ports without actually reconfiguring either the client or the service. Is that possible?
If you are to read/listen/capture the data then it does not need to be a proxy. I would recommend WinPcap library (http://www.winpcap.org/). Although it's a C/C++ library, I don't think it's hard for a C#/.NET application to make use of it.
If you wanna redirect the ongoing connection as soon as your proxy program is up, the short answer is hard, really hard and impossible. As far as I've known, once the connection between 2 ends is established, no way you can change it (unless you have access to the router and modify its NAT on the fly, like a load balancer...). If you just want to read & not to modify the traffic data, use WinPcap or any packet sniffer. Either of these solutions are quite expensive to implement in term of money and technical work :)
Because you didn't give us what you actual wanna do, I assume that you don't need that "much" complexity. Here a solution just in case you meet the following prerequisites:
The client connects to the service via a domain name, not an absolute IP and vice versa. This is important because we are going to change the DNS in the host file to "fake" the end-point servers to our proxy server address.
You have access rights (administrator) to the client machine & the service machine to make any change.
Then what you should do next is to:
Change the IP of the hostname of your service server on your client machine to the IP of the proxy server. This just changes the result of the OS DNS resolver. Do the reversing way for the service server.
Drop & re-establish connections between 2 client machine & service server. Now, each connection is properly "proxied" via your proxy server.
Ha, quite intricate but it works I think... Hoping someone has better solutions for this situation and I'm looking forward to hearing that.
Tooday I use ServiceHost for self hosting WCF cervices.
I want to host near to my WCF services my own TCP programm for direct sockets operations (like lien to some sort of broadcasting TCP stream)
I need control over URL namespaces (so I would be able to let my clients to send TCP streams directly into my service using some nice URLs like example.com:port/myserver/stream?id=1 or example.com:port/myserver/stream?id=anything and so that I will not be bothered with Idea of 1 client for 1 socket at one time moment, I realy want to keep my WCF services on the same port as my own server or what it is so to be able to call www.example.com:port/myWCF/stream?id=222... and I want it to work on Any port - not only 80)
Can any body please help me with this?
I am using just WCF now. And I do not enjoy how it works. That is one of many resons why I want to start migration to clear TCP=)
I can not use net-tcp binding or any sort of other cool WS-* binding (tooday I use the simpliest one so that my clients like Flash, AJAX, etc connect to me with ease).
I needed Fast and easy in implemrnting connection protocol like one I created fore use with Sockets for real time hi ammount of data transfering.
So.. Any Ideas? Please - I need help.
Well if you're going to drop down to pure sockets, you could as well make your service act as proxy. Make WCF Services listen on some other port, and your app on the desired port. When you receive request in your app, manually parse header and check weather it is intended for your service or WCF Service. If it's intended for WCF service, open a TCP connection to WCF service and pass the received data to it, and then simply pass back WCF's answer to the client..
On the other hand you could speed up WCF quite a lot by writing your own custom binding. Lots of time WCF looses on serialization that is done using reflection (which is slow), going around this would improve your speed considerably.
If your problem with WCF is performance then you should try the binary net TCP binding to eliminate XML serialization to improve performance.
Some high traffic applications, like realtime games, use UDP for the majority of communication since it cuts through the protocol. With TCP you get ordering and reliability built in, but this comes at the cost of performance because it will implicitly delay packets to wait for out of order packets so that it can hand them to the application in the correct order, or wait for lost packets to be resent. Instead you can use UDP and implement your own scheme for verification of data that is less stringent than TCP.
There are UDP options available for WCF, or you could implement your own. WCF is nothing more than a message pump, and you can replace different steps with whatever you want.
Not sure if this will help you or not, but try turning on your Net TCP Sharing Service.