Can anybody tell how two bittorrent clients exchange data if both are behind different NATs. If there is no port forwarding and both doesn't allow incoming connections. I didn't find any text that explains the NAT traversal used by bittorrent.
Bittorrent use TCP.... Can two bittorrent peers communicate if both are behind different NATs?? If yes please if you can tell the summary or the name of technique or can refer to some paper that explains that stuff.
there is a thing called Foreign and Home Agents ... borrowed actually from mobile IP concept... if you sit behind the NAT you need to establish a connection with agent with public IP. In this case your NAT will create a tunnel between YOU and AGENT ... then your only have to publish this temporal tunnel, IPEndPoint to be precise. As agent could serve static server or other users like it's done in Skype, where anyone follows this procedure.
Now consider connection establishing Peer1 -> Peer2:
1) Peer1 creates tunnel with static server (Home Agent)
2) Peer2 creates tunnel with his Home Agent (could be the same server)
3) Peer1 asks for tunnel for Peer2
4) Home Agent sends back to Peer1 temporal IPEndPoint of Peer2
5) Peer1 sends packets on this EndPoint.
P.S. there is a small problem with implementation of this thing in .NET - it throws an exception when there is more than one sockets bind to the same port. So, you have to terminate previous connection and start to listen the same TCP port.
Thanks for your reply. Can you tell me who host these Agents or Static server? you gave the example of Skype, which use supernodes for this purpose and anybody on the public IP could act as supernode. But in case of bittorrent are these static servers hosted by some well know ISP or something??
And the technique you have explained for NATs is understandable and its very good for UDP traffic but I've experienced there are lots of issues with TCP when we use this technique. When both the clients are behind NAT and we try this technique, first we will have port binding issues for (PORT_REUSE). Also this technique will work fine with FULL CONE NATs but when it comes to commonly used Port Restricted NATs.... It will be messy with TCP.... Any comments?
My experience tells me that C is much better than any higher level language, like C# or Java ... Because despite you have to implement everything by yourself, it's easier to manage problems like you 've mentioned. I had also many problems with implementation of this on my private Agent server starting from binding TCP socket up to closing it... Eventually, it led to development of my own protocol described here: http://forum.bittorrent.org/viewtopic.php?id=77
So, now I just follow aforementioned logic on my private Agent server using my own protocol ...
P.S. I'm very sorry but for now it's unavailable for public use.... maybe next year ...
Last edited by zhah (2008-11-28 09:12:54)
I know this topic is so old but,
Im tryint o understand IPEndPoint since Im implementing a p2p application for file-transfering and I am not beeing able to connect to hosts behind nats.
When you say that "Home Agent sends Peer 1 IPEndPoint of Peer2"
WhatÂ´s really happening? Home Agent is redirecting all packets from one peer to another? Or peer 1 and 2 will really have a TCP connection, how will the 3-way-handshake occur?
First thing is that I assume you are not implementing bittorrent protocol and you want to implement your custom protocol for peer to peer file transfer. I had kind of same requirement and after all the research the conclusion is that the suitable protocol for this purpose is UDP. It is comparatively very difficult to implement p2p behind NAT using TCP. Now you also need reliability as you are transferring the files so the best solution is to try UDT protocol. The UDT is an open source library that is build over UDP protocol and it adds TCP like connections, reliability on top of UDP. Also the UDT is NAT friendly and a very good choice for P2P applications.
Now about connecting the peers behind NAT. I implemented a custom STUN server for that purpose which helps two peers behind NAT to connect to each other. The STUN server is hosted on a public IP (with no NAT). Suppose peer-A want to connect to peer-B and both are behind NAT. In this case both peers need to discover their public endpoints (the IP/Port of the Gateway or Firewall). For that purpose you send a UDP packet to STUN server and STUN checks the source IP of that packet. As this packet comes through you Gateway or Firewall, so its source IP/Port will be the public endpoint when it reaches the STUN. Once you discover public endpoints of both the peers, then peer-A can ask STUN to send its public endpoint to peer-B and also the peer-B will ask STUN to send its public endpoint to peer-A. Now both peers have each other's endpoints. Now you can directly send packets to each others' public endpoints directly.
If you are using UDT then look at rendezvous connection mode when you want to send packets to each others' endpoints directly.
For more information you can google for "UDP Hole Punching"
You can find UDT protocol library at,
Hope it helps.