← Back to team overview

linuxdcpp-team team mailing list archive

[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