Developing P2P Protocols across NAT
Due to their long length, the listings for this article are located on the Linux Journal FTP site at ftp.linuxjournal.com/pub/lj/listings/issue148/9004.tgz. I leave out unnecessary detail and glue code and focus purely on the nontrivial aspects of UDP hole punching.
If you need more information on implementing your own hole punching library, you always can refer to the above design constraints and design a solution appropriately.
Please note that I have consciously left out the rfcs and NAT discovery techniques, such as STUN and frameworks like ICE. UDP hole punching is already complicated, and we don't gain anything by making it even more bloated without adding any real value. So, the technique as it stands works as good or even better than other NAT traversal mechanisms.
First, take a look at the rendezvous code (Listing 1). Note that we use select() to serve multiple sockets. We could as well use kqueue() on *BSD, or better, use the libevent abstraction (see Resources). But, I stuck to select() because performance doesn't matter so much to us. We talk to the mediator server only for establishing peer-to-peer connections, not otherwise.
The hole punching implementation is given in Listing 2 and the P2P client in Listing 3.
Using this method, you should be able to develop your own peer-to-peer protocol. You easily can develop your own instant messaging protocol along with some GUI code. You can transfer files either using nc or using code for that directly. You can develop certain applications, such as transferring voice via a microphone and speaker. In other words, you can develop a hobby VoIP application with this.
Several possibilities exist. You can add some reliability on top of UDP in case you are paranoid about your data reaching you safely.
One very useful tool that helped me immensely in this endeavor is the Network Swiss-Army knife, netcat.
You can see hole punching in action by using this simple command. At each end, type:
$ nc -u -p 17000 <peer public IP> 17000
With only the peer public IP different, you can start communicating if you are lucky, because most NAT devices try to assign the same private port as the public port.
If you want to test TCP hole punching, try this:
$nc -l -p 17000
at one end and this:
$nc -p 17000 <peer public IP> 17000at the other end.
Rather than having one rendezvous server, you can have a few of them for failover and geographical distribution. However, if you are behind two levels of NAT, sometimes this may not work. You also could listen on multiple virtual and real interfaces and attempt hole punching on all of them. You can add TCP hole punching on similar lines and try that first, and then attempt UDP hole punching.
Resources for this article: /article/9072.
Girish Venkatachalam loves to play with open-source operating systems, such as OpenBSD, FreeBSD and Debian GNU/Linux. He also likes to go cycling when not hacking. He can be contacted at firstname.lastname@example.org.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- My Network Go-Bag
- Firefox Security Exploit Targets Linux Users and Web Developers
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development