4 ms·
This works and it works reasonably well. I had used simultaneous-open TCP punching as a fallback for UDP punching when I was doing [0] and it did help in 10-20
by latitude 13y ago
This works and it works reasonably well.
I had used simultaneous-open TCP punching as a fallback for UDP punching when I was doing [0] and it did help in 10-20% of cases when (a fairly elaborate version of) UDP punching failed. That's on a scale of several hundred thousand mediated connections per day.
One caveat though is that it requires implementing a bot-like functionality in the clients, meaning that a mediating server should be able to tell a client - "create a socket, bind it to this ip:port, wait, wait... connect to that ip:port". Obviously, this is an ideal platform for DDoS attacks if someone ever manages to re-point clients to a rogue mediation server. So, yeah, it works well, but there are some not so obvious trade-offs.
[0] http://swapped.cc/hamachi http://swapped.cc/hamachi
- steeve 13y agoAh! So that's how you guys did it! I always wondered what you were doing beyond UDP hole punching.
- malloc2x 13y agoIs there a Free software package that does something like this today?
- synctext 13y agoTCP simultaneous open is very difficult to use. In our experience with a deployed P2P system, UDP hole punching is more successful with all the strange NAT boxes deployed. Our success rate is 95.3% now in the wild. As said above, this TCP fallback sounds like an excellent way to get to 97% connection success rate! Note that there is an upcoming IETF Internet Standard describing UDP hole punching: http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-06#section-3.10 http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol-06#... We've implemented this as LGPL code: svn.tribler.org/libswift/branches/ppsp-03/