0

Would anyone know the answer to this?

I was reading Practical JXTA II (also at http://www.scribd.com/doc/47538921/Practical-JXTA-II). I'm confused by the statement on page 92 second paragraph concerning establishing communication with a peer behind a NAT : "such peers remain inaccessible ...until either ... or b) inaccessible peer establishes a connection to the remote peer spontaneously."

This seems to imply that the NAT translation of IPv4 local addresses to public addresses is always the same. If the router is mapping a large set of addresses to a smaller set of public addresses wouldn't the results vary? Once the HTTP response is received then the session would be terminated and someone else could use that public IP, right? Once the HTTP session is over the router would no longer record the mapping used.

I'm trying to implement an idea for Web Services where an aspect of the application is P2P (I need both nodes to act as both client and server at times). The central server can have a DNS registered address but the various potentially mobile nodes might be behind NATs etc. After reading this I thought I would be ok if I had the nodes behind NATs establish a connection when they start up, telling the central DNS register node their public address, but now I'm thinking that address would likely change.

user1069528
  • 618
  • 1
  • 13
  • 29

1 Answers1

0

Her is my understanding of what Jérôme meant.

Say peer A is WAN-visible and peer B is behing a firewall. Peer A can send data to Peer B, when

  • Peer A and Peer B both establish outbound connections to a relay server. Peer A sends data to the relay on the outbound request that the relay forwards to Peer B on the synchronous response (of peer B connection to the relay).

  • Peer B establishes a connection to Peer A, and peer A sends data back to Peer B on the synchronous response. A "reverse-invoke" mechanism.

wrt to JXTA, a peer publishes to the network a local address and optionally a WAN address (address is the couple host+port). There can only be one WAN address per peer if you want to establish direct connection to that peer using NAT.

Having a central server is a bad idea in a P2P network: you create a single point of failure, which is exactly what P2P networks excel at avoiding.

Yet, as you hint, there is still a need to maintain a registry of "adresses/peer locations". This registry has to be distributed however. This would need a book, but here are two approaches:

  • a Distributed Hash Table (DHT) on the nodes: every node holds and share a copy of part of the registry. JXTA has such a mechanism but check Kademlia on Wikipedia for a very successful algorithm.

  • a Global Index Nodes approach (I believe Skype-like): a limited number of dedicated peers/nodes that hold the registry using DHTs or other replication algorithms. The peers connect to the GINs for addresses using firewall friendly protocols (HTTP) and the GINs talk to each other using fast socket-to-socket connections (check Hazelcast for a quick way of implementing GINs).

Bruno Grieder
  • 28,128
  • 8
  • 69
  • 101
  • Thanks. I'm planning a commercial application that isn't pure P2P. I would require a central coordinator by its nature. So as you suggest I would have to consider failure -- probably use clustering etc. – user1069528 Jun 04 '12 at 20:22
  • I suppose once IPV6 is installed in the major commercial networks this will primarily only be an issue in corporate networks where there is an interest in hiding real ip addresses. My primary interest is mobile devices. – user1069528 Jun 04 '12 at 20:26