"pho-nat" - cool stuff… so now i'm wondering if nanomsg high level protocols can be used with a UDP transport. Jay On Mar 25, 2015, at 12:45 PM, George Walker <georgewalkeriv@xxxxxxxxx> wrote: > Neither TURN not STUN servers are required for peer-to-peer NAT traversal. > But Jay is correct: doing so would require a UDP-based transport. > > See pwnat: samy.pl/pwnat/ > > It uses a really clever trick which would be need to be ported to nanomsg to > permit p2p NAT-to-NAT connections without the assistance of a non-NAT > "supernode" to act as a relay and termination point for outbound TCP > connections. > > Since you can't initiate a TCP connection to machine behind a NAT device, > NAT-to-NAT hole punching techniques like pwnat use UDP hole punching, wherein > both hosts fire UDP packets at one-another's public IP addresses > simultaneously so the incoming packets look like responses to outgoing > packets. Pwnat's innovation was the use of ICMP as a signal that the > previously unknown initiating peer (acting like a client) can send to the > receiving peer (acting like a server) to initiate the hole-punching process. > The pwnat man page describes the details better than I recall them. > > > George > > > Sent from my iPhone > >> On Mar 25, 2015, at 2:27 PM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote: >> >> TURN might require some kind of support in Nanomsg, but you can also use >> nn_device() on NAT-free nodes in order to do something very similar without >> any changes to Nanomsg. >> >> Jay Berg wrote: >> >>> Im dealing with distributed autonomous p2p protocols like bitcoin. Need >>> to connect to multiple peers, and do not want to rely on third party >>> servers. >>> >>> if peers can't connect without 3rd party server, then they will just move >>> on to the next peer. Its ok if some of the nodes are only able to connect >>> to non NAT ips. >>> >>> even if I use TCP hole punching, this would still require a new nanomsg >>> transport. or am i missing something? still researching this stuff. >>> >>> >>> On Mar 25, 2015, at 10:44 AM, Alex Elsayed >>> <eternaleye@xxxxxxxxx> wrote: >>> >>>> Um, not really. With TURN, you'd be able to use TCP across both-NAT. >>>> >>>> TURN does have downsides, but those are really best laid at the feet of >>>> NAT. >>>> >>>> There's also the option of a "supernode"-style system, where non-NAT >>>> peers TURN for their NATted siblings. >>>> >>>> Jay Berg wrote: >>>> >>>>> to use nanomsg , I would need a new transport. >>>>> >>>>> //www.freelists.org/post/nanomsg/is-there-a-nanomsg-socket-type-unaffected-by-natfirewall,2 >>>>> >>>>> this is a big issue with p2p / blockchain technology. I have a p2p >>>>> system using nanomsg protocols, and I'm hoping i don't need to rip out >>>>> all the nanomsg stuff… >>>>> >>>>> >>>>> >>>>> On Mar 25, 2015, at 9:07 AM, Brian Empson >>>>> <brian@xxxxxxxxxxxxxxxxxx> wrote: >>>>> >>>>>> You will need a third host that both hosts can reach outside of the >>>>>> NAT'ed networks to do this. I don't think you'll need another >>>>>> transport. >>>>>> >>>>>>> On Wed, 2015-03-25 at 08:47 -0700, Jay Berg wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> >>>>>>> To use nanomsg when both sides are behind a NAT, we will have to >>>>>>> implement a new nanomsg transport. >>>>>>> >>>>>>> >>>>>>> From what I understand, NAT hole-punching is more reliable using UDP >>>>>>> vs TCP. >>>>>>> >>>>>>> >>>>>>> Would the nanomsg protocals all work with a UDP transport? >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Jay >> >> >> >
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail