STUNT / ICE / Tunnelling support.

[jlouis]

Or in general: Add UDP/TCP hole punching. Other clients support this and it shouldn't be hard to add. Seems there are no BEP for it yet though :/

[edwardw]

The current state of the art implementation should be Apple Facetime. The standards behind it, it regarding to NAT traversal, are still STUN, TURN and ICE. Should be nice if etorrent has them in addition to UPnP.

[jlouis]

Sounds like a good place to look for the state of the art, indeed!

[edwardw]

Yxa, a sip server in Erlang, has a STUN server implementation. May or may not be useful.

[edwardw]

This is a mess. Regarding protocol, it is well defined by IETF RFCs. But there are two main obstacles AFAIK: the lack of well known STUN/TURN server and that two peers may all need to understand the protocol.

• STUN/TURN needs a server somewhere in public internet to help punching the hole. In case of TURN, even to relay traffics. I can't find a list of well known STUN/TURN servers.
• In two scenarios, two peers communicating with each other need to talk the same protocol. One is when one peer acts as STUN/TURN server since there's no one available. The other is when two peers are both behind NATs.

Proprietary extensions make things worse. Microsoft has a STUN-like protocol called Teredo, which may have some servers operated by Microsoft. Miredo: http://www.remlab.net/miredo/ is a Teredo implementation for Linux and BSD (OS X also?). Regarding BitTorrent clients, uTorrent's protocol, uTP (BEP-29), has a proprietary STUN technique "ut_holepunch", which is undocumented.

This thread in transmission forum is informative: https://forum.transmissionbt.com/viewtopic.php?f=3&t=10308 It helps me to understand current situation.

Protocol wise, although there're many, they are all able to be implemented at least. Operating a public server and the lack of agreement regarding NAT traversal between BitTorrent clients are out of the scope of our little project ;)

[jlouis]

Thanks for looking into this mess. I am pushing for a uTP implementation right now. Will probably drop code tomorrow with what I have, so you can join the fray at that point.

Teredo/Miredo is also IPv6 tunneling IIRC. Perhaps we should ignore the mess for a bit and work on other things?

[edwardw]

Kudos to your uTP implementation!

[edwardw]

Teredo is IPv6 tunneling, yes, by wrapping IPv6 in UDP packets. So as far as NATs traversal is concerned, it is pretty much the same as STUN. Even better since it is system wide, not per application.

[edwardw]

This itches me, a lot ;) I may give it a second shot. To bootstrap the development, i.e. circumventing the lack of public stun server, the plan is to:

• set up a little stun server myself, using https://github.com/adamfisk/littleshoot-stun-server
• then develop a erlang stun client against littleshoot stun server
• at last develop a erlang stun server with this fresh erlang erlang stun client

In other words, if all goes well, etorrent will be both stun client and server. Two etorrent instances should be able to talk to each other. The one in public internet will be the stun server to help the other traverse nat. Co-operating with other bittorrent client implementations will be secondary to this main goal.

[edwardw]

Aforementioned approach works. It has been confirmed that Littleshoot STUN server is functional. And STUN binding messages have been successfully exchanged between Littleshoot server and an Erlang process. Now it's time to write a STUN client for etorrent!