Develop Reference

Using TURN server for peer-2-peer communication

I’m very new to TURN and I want to create an experimental application which requires a TURN server for its udp communication.
I have used UDP hole punching already and I’m familiar with the subject.Also I know about NAT types and UPnP for port mapping.
To solve port mapping in Symmetric and Port restricted NATs with routers without UPnP capability I must communicate with a TURN server and send UDP packets through it.But I don’t have any idea how to communicate with TURN server and how to work with it in C# programming.
I’d appreciate it if you could point me to the right direction and give me some pointers.
Thanks.

I can answer about how to use TURN for completing a relay call. But to know how to form messages for TURN you need to read the RFC.
How TURN Works
TURN is needed because its impossible to bypass some NATs filtering and establish direct connection with a host. As TURN sits on a public IP, anyone can connect with it.
So hosts under symmetric NAT can send allocation request to TURN server and TURN server will allocate a port for the host. Now the host will have IP information of the other side. And it will send another request to TURN specifying the IP info of other host and packets from that other host in the allocated port will be forwarded to the host behind the symmetric NAT. And packet from the host behind the symmetric NAT will be forwarded to the other host. This way they create a relay connection.
You really need to read the RFC for TURN to know this in more details. Everything you need is there.

#tahili I see this is an old post but I want ask you a question.
If Turn server can reach the peer's server-reflexive address why can't the client just send packages directly to peer's reflexive address. If client can't send data to peer directly because of mapping problems how does the turn server can send a udp to peers server reflexive address.
Mind you peer has not contacted the turn server yet "relay address of the client", so there is no mapping between the turn server(client's relay address) and the peer.
Knowing peers reflexive address alone is nor enough. After all we can just send data directly to the peer.
Assuming is peer is behind NAT as well.

Does WCF offer options to avoid port forwarding?

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.

how do applications connect to servers without the need of portforwarding?

I just created a simple chat client and it only works when all clients / server are portforwarded on the same port.
How do i make my application (its in c# and uses .net sockets btw) work without the need of port forwarding for clients (i dont care if server needs to port forward).
it uses udp by the way.

I believe you titled your question wrong. You are talking about the server connecting to the client, right?
If you are working directly with sockets, the short answer is - you can't. The long answer is that the client has to register with server in such a way that the client port is held open so the server can reach it.
Rather than writing this yourself, consider a library that is focused on this, such as SignalR.
Besides - UDP is a horrible choice for a chat client anyway. There are plenty of jokes about UDP packets, but trust me - you won't get them all.

If there is NAT and/or a firewall between the two endpoints, that hardware decides if the two endpoints can communicate, not your program.
However, NAT and firewall rules frequently allow Port 80 and other ports < 1024 inbound. Often, any outbound port can be reached. You can leverage this to minimize the likelihood that the network topology will block communication. In fact, if you look at the Advanced / Connection tab of Skype, you can see that there is a checkbox indicating whether Skype can use ports 80 and 443 for incoming connections (this setting sometimes interferes with a web server on a developer machine...).

You need a server somewhere in the middle that all the clients connect to. You cannot have 1 client behind a nat box connect to another client behind a nat box. They both need to connect to a server and keep that connection open. Client A then sends a message to the server which forwards the message onto client B.

If you want to communicate through a NAT router, you can setup your portforwarding using UPnP from within your application. This is how for example torrent programs can communicate without having you to setup portforwarding.
In .net you can use the NATUPnP 1.0 Type Library (NATUPNP.DLL) COM Component, which is part of Windows (since Windows XP).
Add a reference to the com component
Get a list of all existing port mappings
NATUPNPLib.UPnPNATClass upnpnat = new NATUPNPLib.UPnPNATClass();
NATUPNPLib.IStaticPortMappingCollection mappings = upnpnat.StaticPortMappingCollection;
Iterate through all mappings
foreach(NATUPNPLib.IStaticPortMapping portMapping in mappings)
{
// do something with the port mapping, such as displaying it in a listbox
}
Add a new Port Mapping
// Here's an example of opening up TCP Port 80 to forward to a specific Computer on the Private Network
mappings.Add(80, "TCP", 80, "192.168.1.100", true, "Local Web Server");
// Here's an example of forwarding the UDP traffic of Internet Port 80 to Port 8080 on a Computer on the Private Network
mappings.Add(80, "UDP", 8080, "192.168.1.100", true, "Local Web Server");
Remove Port Mapping
// Remove TCP forwarding for Port 80
mappings.Remove(80, "TCP");
// Remove UDP forwarding for Port 8080
mappings.Remove(8080, "UDP");
Source: http://pietschsoft.com/...

Socket programming: The Server

Ok so I've been trying to teach myself some socket programming. I wrote myself a little C# application with an async server and I understand most of it, except for the following:
So the server has a port it listens on for connections then when it receives a connection it creates a different socket to do the communication on. This it what I dont understand... How does the communication happen between the client and the server when in theory the client has no idea what port has been elected for this new connection?
Thanks for all your answers
Edit: As far as I understand the listening thread listens on the default port, but all messages are then handled on a different socket for each client?
Edit Again: Some how you guys are misunderstanding my question. I understand normal socket communication. My problem is with an async server where the listening socket is different from the connecting socket. Ie.
Server listens on default port
Client attrmpts to connect.
Server receiver request.
Server then creates a communication socket between client
and server and continues listening
on the default port.
My problem is at the last step. How does the client now know how to communicate on the new socket?
Here is some sample code
http://msdn.microsoft.com/en-us/library/5w7b7x5f.aspx

Although this question was posted over a year ago, I belive it is worth trying to clarify (or confuse?) it a bit more.
"How does the client now know how to communicate on the new socket?" - The client is not aware that a new socket was created. It simply keeps on sending data (packets) to the same port.
However, this gives rise to another question: How does the server know which data comes from which client? - Thanks to the TCP and IP protocols the server knows both the address of the client and the source port from which the packets were sent. With this information the server can receive packets from multiple clients and multiple (client) ports and route them to the correct socket. For this question, think of server sockets as filters: when packets are received from client X - port Y then route them to socket Z.
"...does it now know it needs to communicate on a different socket/port?" - This is a frequent source of confusion. When a new socket is created on the server to receive packets (after the connection has been established) it does not use a new port, it keeps on using the original port number. The entire socket creation process on the server side is transparent to the client. The client never knows (nor does it need to know) that a new socket was created to handle its packets.
Google TCP header for more information.
Hope this helps someone.

When the client connects to the server, it selects the port to connect to. The client also includes a port that it will receive responses on. This is typically a randomly selected port, but it's possible for the client to override that.
Think of it like a phone call. When you call someone, there is the phone number you call, and you also have a phone number. even though you both talk to each other, both phone numbers are in use.
That's not a perfect analogy, since phone numbers are more like IP addresses and trunk lines need not have an originating phone number in all cases, but the same concept applies.
Simply put, the TCP protocol requires an originating port and destination port as well as originating ip address and destination IP. When packets are sent in either direction, the apropriate IP/Port is used either way.

Actually the new connection use the same port. A server listen on a specific port for incoming connection, anytime it receives connection request from client, the server accept it and create a new thread to process the request. And then continue to listen on that port.

Definitions
Client: The socket at the remote machine that is connecting to the server
Server: The socket that is waiting for connections on the server
ServerClient: The socket which is communicating with the Client
Answer
I couldn't find any details about how the ServerClient port is transfered to the Client after the Server has accepted it. But it's most likely transfered in the handshake. Feel free to read RFC793 if you want to know more.
I wont go through the details, but you can read about passive connects to get more information about how listener sockets work at lower levels. But basically the purpose of listener sockets (Server) is only to accept sockets (ServerClient).
The port that the ServerClient uses is assigned by the socket implementation in the operating system and is nothing that you can control. All you need to know is that the each connected ServerClient will get it's own port and it's transfered to the Client during the (threeway) handskake (I think ;))

Communication over WAN

I want to create app client-server in C# but not only in LAN. There it's easy: TcpListener, TcpClient etc.
I want to make sth like in this e.g.
On my comp is server that's waiting for a connection.
Someone in another network has client. He begin connection, but...where...what is a IP of server?
He see only ip of router.
Any ideas? :)
EDIT
Big problem is also double-NAT

You still use the same TcpListener and TcpClient (if you want to make it that low level).
The technologies for communicating over a WAN are the same for communicating over a LAN. The difficult part is getting the networks in between the client and server to allow you to use the necessary ports and protocols.

You question doesn't explain the whole scenario.. but with my understanding of the problem I can suggest the following answer:
Depending on the Target customer base's locations (support for Corporate networks or NOT), you can use various routing options like UPnP, STUNT or IPv6, or some other NAT traversal options, so that you can inform the client about where the listener is. There should always be a central registry server to which the Listener would inform its whereabouts and the mode of the communications permitted in its environments. Use of an XMPP server would be an easy option for such purposes, which solves most of such issues. Once the client queries about the location of the listener from the discovery server, it can directly connect to the Listener.

Sounds like you just want to set up port forwarding on your router. When an incoming connection is made on the specific port a client connects to, the router should redirect the connection to the machine you specify on the LAN. (Usually an IP like 192.168.x.x). This should also be the IP address your TcpListener is listening for connections on.
You can try portforward.com if you need help setting it up for a particular router.