As you know, we participated in the Google summer of code 2015. One of the projects accepted for our organization was "NAT traversal via hole punching Set of Rules" by the student Max Mertens. In this post, Max tells us about his experience. Thanks!
Peer-to-peer software is a great idea, as you do not need a central server and save bandwidth necessary for relaying. As I have been interested in networking and protocol development for a few years, I was happy to find the P2PSP organization and that it is participating in the Google Summer of Code 2015. So I asked the P2PSP developers if they would need an implementation of NAT traversal in their software, and applied for GSoC with the project "NAT traversal via hole punching Set of Rules as a Python implementation". The main idea of the NAT Traversal Set of rules (NTS) is that two peers (computers) that are each behind a different router (Network Address Translator, NAT) can connect to each other, without prior configuration of port forwarding and without UPnP or similar techniques. This enables multimedia to be streamed between such peers, e.g. between PCs or mobile devices each behind a home router.
The mentors Vicente González Ruiz and Juan Pablo García Ortiz accepted the project ("any improvement in the NAT's war is also interesting for us") and I was very happy to be able to work with this organization over the summer.
I began with the project by examining existing NAT traversal software and setting up a testing environment. Then I worked on a simple Python script doing nothing but NAT traversal. After testing and improving it, I added the NTS classes to the P2PSP software and added more and more functionality, until NAT traversal was working for all theoretically possible combinations.
During the project, I sent status report emails once or several times a week, and my mentors Vicente and Juan Pablo helped me if I was unclear about P2PSP code or principles, and they had creative ideas on extending the NTS code. Also they were always open to merge changes to existing P2PSP code that were necessary or helpful during development.
A few practices emerged that were helpful during development: To stick closely to the timeline that was planned in the proposal and to keep track of outstanding tasks, I had a frequently updated task list with finished tasks for each week and a to-do list sorted by priority. This way it was easy for my mentors and me to see how many tasks are left and what is to be done next. Documentation can turn out to be much more work than necessary if you document any change you made to the project. So I aimed at documenting each small part of the code just after it was finished and was not likely to be changed much anymore, and finalized the documentation before the midterm and the final evaluation to fully match the code.