With the recent announcement of uTP availability in the alpha build of uTorrent (14981) the possibility of integrating NAT traversal methods into the BitTorrent protocol arise. Quick description of uTP from the uTorrent site:
"uTP, the micro transport protocol. This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it. In addition, we use information from this transport, if active, to control the transfer rate of TCP connections. This means uTorrent, when using uTP, should not kill your net connection - even if you do not set any rate limits."
Yes, reliable UDP transfers. Many applications like Skype or Hamachi use UDP to get thru NATs, the method is called UDP hole punching. It is a very simple method with great success rate: "...who recently found that of the top three consumer NAT router vendors, representing 86% of the NATs observed on their network, all three vendors currently produce NATs compatible with UDP hole punching".
How does it work? Citation from wikipedia: "The basic idea is to have each host behind the NAT contact a third well-known server (usually a STUN server) in the public address space and then, once the NAT devices have established UDP state information, to switch to direct communication hoping that the NAT devices will keep the states despite the packets coming from a different host.
Let A and B be the two hosts, each in its own private network; N1 and N2 are the two NAT devices; S is a public server with a well-known globally reachable IP address.
1. A and B each begin a UDP conversation with S; the NAT devices N1 and N2 create UDP translation states and assign temporary external port numbers
2. S relays these port numbers back to A and B
3. A and B contact each others' NAT devices directly on the translated ports; the NAT devices use the previously created translation states and send the packets to A and B"
Exactly, the problem is the "third well-known server" which we don’t have without having to change the BitTorrent Tracker code. Only if we would use other clients for this "initialization" e.g.:
- the client gets the list of other clients from the Tracker response or thru DHT
- the client tries to connect using UDP with fallback to TCP
- if successfully connected thru UDP:
-> the client sends a hello packet
-> the respond will contain its public IP:port
-> the client then updates the tracker on his port address
-> other clients will be able to connect to that client using that port
-> if in any hello reply the client gets a different IP:port the tracker is immediately updated
Ok, this is basically working, only a few problems left to solve:
- on some types of NAT multiple attempts will be needed to establish the connection, it would be necessary to always try to connect to all the other UDP clients the local client knows of. For example with maximizing the num_want parameter in the tracker requests.
- UDP Idle Timeouts, the goal is to keep the single IP:port combination for every client up as much as possible. To do that regular keep-alive messages would be required. The process of "hello-ing" all the other UDP clients all the time nonstop would be a solution.
The presented approach would not need any change on the tracker side, only a minor modification to the client software would be required. This method would not work in 100 percent of scenarios but as already stated getting 80 percent is possible.
You can find a simple demonstrator code attached.
The server.c simulates the "already UDP accessible host" and the Tracker as it sends back the IP:port of the other host. The client.c code sends the request on the server and then communicates with the other client.
http://en.wikipedia.org/wiki/UDP_hole_punching
http://forum.utorrent.com/viewtopic.php?id=49813
http://www.brynosaurus.com/pub/net/p2pnat/
