linuxdcpp-team team mailing list archive
-
linuxdcpp-team team
-
Mailing list archive
-
Message #06930
[Bug 1185436] Re: feature: p2p connection between two passive clients
this was implemented 3 years ago:
- <https://dcpp.wordpress.com/2010/02/13/passive-mode-c-c-connections-and-nat-traversal/>
- <http://dcpp.wordpress.com/2010/06/15/nat-traversal-constraints/>
** Changed in: dcplusplus
Status: New => Invalid
--
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/1185436
Title:
feature: p2p connection between two passive clients
Status in DC++:
Invalid
Bug description:
There is a possibility to implement a direct p2p connection between
two passive clients, by utilizing the same technique that Skype uses
for VoIP calls, named "UDP hole punching" and is explained in detail
here: http://en.wikipedia.org/wiki/UDP_hole_punching
There is a more complicated "TCP hole punching", but UDP version is
much much easier to implement. It would be interesting to implement
some kind of transmission control over udp to achieve this
functionality, which would really make p2p software like dc++ really
cool and functional out-of-the-box.
Short explanation how this could be implemented. Assume two passive clients A and B want to connect to each others to share files:
1. client A binds its udp socket to local_port_A and sends a message, through the hub, to client B about that port number
2. client B receives the message, sent in step 1, and binds its udp socket to local_port_B and sends the udp packet to client A directly to his ip address and port local_port_A. this udp packet will be discarded at client A's side, but it will "punch the "hole" in the client B's firewall, allowing now client A to send udp packets to client B (firewalls assume that if you sent the udp packet to a remote side, then remote side will probably answer to you using the same port mapping). at this point, client B will send the message through the hub to client A, to inform it about its local_port_B
3. after client A receives the message, it can now send udp packets from its local_port_A directly to client B to local_port_B and from now on they can communicate normally, without firewall issues
The only thing to really implement here would be the transmission
control which would make sure no packets are being lost and if any
packet is lost, to resend it again. That's all.
P.S.
The above "punching" for each connection request can be avoided by putting the local_port_X of the client X into $MyINFO or something like that, which would instantly inform other clients about the chosen udp port so the p2p connection can start immediately.
To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/1185436/+subscriptions
References