Thiago,

But I want to establish a p2p connection between two peers in different 
networks behind a router and from what I have been reading, one of the 
approaches is UDP punch holing where you first contact a server that is is 
outside your network so that it can tell you your public IP address and 
assigned port. At this point, the firewall/nat has mapped a port outside and 
during a variable time interval, you are able to keep that port open if traffic 
flows. At this point, you tell the other peer which IP and port it should 
contact you from, achieving a peer 2 peer connection between the two UDP 
sockets. The STUN serves is the outside entity that you tell you the IP and 
port it was contacted from.

from wikipedia (https://en.wikipedia.org/wiki/STUN 
<https://en.wikipedia.org/wiki/STUN>)

"Session Traversal Utilities for NAT (STUN) is a tool used by other protocols, 
such as Interactive Connectivity Establishment (ICE), the Session Initiation 
Protocol (SIP), or WebRTC. It provides a tool for hosts to discover the 
presence of a network address translator, and to discover the mapped, usually 
public, Internet Protocol (IP) address and port number that the NAT has 
allocated for the application's User Datagram Protocol (UDP) flows to remote 
hosts. The protocol requires assistance from a third-party network server (STUN 
server) located on the opposing (public) side of the NAT, usually the public 
Internet."

"The basic protocol operates essentially as follows. The client, typically 
operating inside a private network, sends a binding request to a STUN server on 
the public Internet. The STUN server responds with a success response that 
contains the IP address and port number of the client, as observed from the 
server's perspective. The result is obfuscated through exclusive or (XOR) 
mapping to avoid translation of the packet content by application layer 
gateways (ALGs) that perform deep packet inspection in an attempt to perform 
alternate NAT traversal methods."


Can you please be more specific when you say, use a UDP-capable SOCKS5 proxy 
server?


As far as I can tell, I’m receiving the response from the STUN server on the 
requesting socket and the request is parsed as valid so I assume this STUN 
server is SOCKS5 compatible, if this is what you mean. However I can’t seem to 
receive data that is being sent from QUdpSocket opened on other computer, in a 
different network to that IP and port. 


Sorry for any imprecision from me, I’m a bit lost here...


Thx!

Best regards,

Nuno
 
> On 18 Dec 2017, at 18:09, Thiago Macieira <thiago.macie...@intel.com> wrote:
> 
> On Monday, 18 December 2017 09:53:52 PST Richard Moore wrote:
>> ​STUN is RFC 5389​ and is anything but simple. Consider using a library
>> that performs NAT traversal for you then wrapping the resulting socket in a
>> QUdpSocket if possible.
> 
> Or use an UDP-capable SOCKS5 proxy server. That is supported.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to