update README (add udp technique); use actual technique identifiers

master
Christian Ulrich 2020-10-25 23:05:22 +01:00
parent 699f8306c2
commit 56d30e8b66
No known key found for this signature in database
GPG Key ID: 8241BE099775A097
1 changed files with 4 additions and 3 deletions

View File

@ -1,12 +1,13 @@
# Introduction
``punchd`` (short for "hole punching daemon") provides TCP (and soon UDP) hole punching as a service to applications. This allows two applications on different hosts, both behind NAT and / or firewalls, to establish a direct communication channel. The motivation is to help peer-to-peer applications improve their connectivity.
``punchd`` (short for "hole punching daemon") provides TCP and UDP hole punching as a service to applications. This allows two applications on different hosts, both behind NAT and / or firewalls, to establish a direct communication channel. The motivation is to help peer-to-peer applications improve their connectivity.
# How does it work?
The idea is to try out a sequence of well known hole punching techniques until one of them succeeds. ``punchd`` implements the following techniques:
- [SYNI](https://www.uni-kassel.de/eecs/fileadmin/datas/fb16/Fachgebiete/UC/papers/HWW_11-SYNI.pdf) (TCP hole punching based on SYN injection), DOI: 10.1109/NCA.2011.66
- [NUTSS](https://www.cs.cornell.edu/people/francis/nutss-fdna.pdf) (TCP hole punching, the non-spoofing approach described in section 4.2.2 of the paper), DOI: 10.1145/1016707.1016715
- [tcp-syni](https://www.uni-kassel.de/eecs/fileadmin/datas/fb16/Fachgebiete/UC/papers/HWW_11-SYNI.pdf) (TCP hole punching based on SYN injection), DOI: 10.1109/NCA.2011.66
- [tcp-nutss](https://www.cs.cornell.edu/people/francis/nutss-fdna.pdf) (TCP hole punching, the non-spoofing approach described in section 4.2.2 of the paper), DOI: 10.1145/1016707.1016715
- [udp](https://en.wikipedia.org/wiki/UDP_hole_punching) (simple UDP hole punching)
The assumption of those techniques is that there is a side-channel (i.e. a rendezvous server) between the two hosts. A peer that wants to be available for hole punching needs to constantly be connected to the rendezvous server so it can be notified by other peers about new hole punching attempts. In addition it needs to provide an endpoint (public IP address and port) to other peers before those can initiate the hole punching. See the example applications for a naive rendezvous server implementation.