In the bitcoin p2p core client, the initial peers are found, as stated, as:
When started for the first time, programs don’t know the IP addresses
of any active full nodes. In order to discover some IP addresses, they
query one or more DNS names (called DNS seeds) hardcoded into Bitcoin
Core and BitcoinJ. The response to the lookup should include one or
more DNS A records with the IP addresses of full nodes that may accept
new incoming connections. For example, using the Unix ``dig command
https://en.wikipedia.org/wiki/Dig_%28Unix_command%29>`__:
source: https://developer.bitcoin.org/devguide/p2p_network.html
Is the same approach required for libp2p for initial peer discovery? I was not able to find any tutorial which covers this information. I was hoping libp2p would handle this problem. Does the libp2p provide guidance or facilities for this?
I have a ReactJS web app that runs on a local network, but is also accessible via a DMZ'd address to a larger local network. The backend is a node server on that LAN, and I realized it will also have to be exposed so browsers on the broader network can get at it.
What is a good way of handling IP addresses depending on which network the user is on dynamically? Users in the LAN would have to have their browsers aimed at 192.168.x.x, say, while broader network users would have to point at 10.72.x.x, as an example, and I don't have a good idea of how to handle this on the fly.
EDIT: I can use something like ip to check my subnet and adjust accordingly, I suppose...not sure this is a best practice.
EDIT 2: I think that maybe I'm not being clear enough from the comments, so here's a little more info:
From the LAN perspective, I need the browser to hit the server at 192.168.25.31, say. And from the DMZ perspective, I need the browser to hit the server at its broader address, 10.72.10.31, for example. The two addresses are known, and static. What I need to be able to do in React is select the correct one of the two based on which subnet said browser is on.
Suppose I have 2 servers. I want to establish a connection between them using socket.io library, and one of them would reach another by .onion link using SOCKS proxy. all the traffic between servers should also go through tor.
I was able to create a simple net socket using onion links, but cannot find how to pass it to socket.io. Is it possible to make socket.io using existing net socket? or maybe there is another way to achieve the ultimate goal?
I have some working experiences with socket.io, but not with the other technologies you mention (so I can't resolve your question entirely). Until someone else resolves it, I will show you a link with about the two modules socket.io-redis and socket.io-emitter that allow socket.io to communicate with the "outside world":
https://socket.io/docs/rooms-and-namespaces/#sending-messages-from-the-outside-world
Ok. I am creating a teamviewer like app. And p2p connection is the best route based on my research on p2p. I want to know weather teamviewer works fully on p2p, and is it possible to create such an app without using any dedicated server and a static public ip address. I mean i do know all nodes in a p2p n/w act equal, but then how will these maintain a connection having dynamic ip addresses. Hoping someone can explain how p2p establishes this.
They do not need a static IP. But in absence of a static IP you need some discovery / address exchange mechanism that allows nodes to find each other.
Overlay networks like DHTs/gossip protocols/supernodes are generally used for such a thing, but it could be as simple as a user manually entering the current IP address.
In practice reachability is a much bigger concern. NATs and Firewalls may prevent incoming connections. If both nodes cannot accept incoming connections then neither can connect to the other.
In BitTorrent, client connects to the tracker specified in .torrent file. Tracker is a kind of centralized server and it is the starting point. So BitTorrent is not pure p2p.
If we want to develop pure p2p system, we should design routing overlay network. All nodes will have routing table like routers do. But even in routing overlay network, each node should know at least one existing node(GUID, IP address) initially. So how can we determine this? Should we keep 'one existing node to connect initially' forever like fixed centralized server? If so, I think this is not fully decentralized method.
The solution you describe (defining a central peer wit well-know ip address) is not the only one.
The other solution is to post an html page (or json file) in a well-know URL on the net, and make sure this item contains an updated list of peers this peer can initialy connect. This list can be updated if a peer goes down. Eventually, you can use multiple URLs.
Pure P2P system is a theoretical concept which cannot be implemented fully in reality.
You could use an anycast. So the first other client will answer and may send such an initial "client list". Where your client can connect to them to get more lists.
Classically I would implement a multicast to a adress and wait for an answer of other clients.
Firstly, a true peer to peer network is not necessarily decentralized. Secondly, decentralization does not necessarily mean that the network doesn't make use of secondary services which may themselves be centralized.
The main question in both of these issues is wheather the primary resources of the network solution are distributed through correlated peers.
For example, peer-to-peer video conferencing may use a central contacts service but still be pure peer-to-peer as long as the peers resolve such issues before entering a true peer-to-peer scope. This would also be decentralized.
What it comes down to is what your trying to solve by using peer-to-peer. A video conference is a video conference - it starts with a video being recorded on one peer and ends with the video being viewed on another. As long as each byte of this data is transferred directly between the peers (even if there's hundreds of peers in the conference, and regardless of how these peers found each other) it is a true peer-to-peer video conference.
Note that the video peers will still be in your typical ring, and that the contacts lists may still use the node key for location information rather than an IP. This will still be a network overlay as it will still be built over IP, replacing it's addressing scheme on the peer level to facilitate true peer-to-peer networking.
What it realy comes down to is the concepts of a network connection. IP just pushes packets to unspecified routers until it gets to a specific address. 'connections' between each endpoint only exist within the higher software levels (including when dealing with TCP/IP). A connection is just the data used within software to understand who is who and how each point can handle data etc. Peer-to-peer network overlays effectively distributes this data, eliminating the need for each peer to create massive amounts of connections to communicate on a massive scope. Decentralization is not required for this (as long as peer to peer communication is not centralized), and a secondary service within the system wont necessarily limit a network's scope or otherwise centralize actual peer-to-peer networking.
So to answer your question, it doesn't matter where it initially connects in order to be considered peer-to-peer, and different peer-to-peer services will handle this based on their service design.
Ok so I am thinking about writing a p2p protocol for a number of different services for an AI project, and I thought I'd come here to see if i could get some ideas on how to get the initial connection.
I have come across several ways to establish the initial connection:
1) You have a static ip address on the internet that distributes information on other peers. This isn't good, because:
a) it's a single point of failure, the service could go offline, preventing any new connections from creating an initial connection to peers,
b) the IP address could change. This could be mitigated by using a domain name which is maintained to point to the current ip address of the location of a service which provides data on peers, however this can be subverted in theory by hackers by spoofing or arp poisoning, dns attacks etc.
2) You could force the user to provide an initial ip address or hostname for another peer, and it's up to the user to find the hostname / ip address / port number. This is good, but if someone posts disinformation or they cannot find a peer on google or some other search site then obviously it's fallable.
3) You could leave it to the peer to publish their own existence in a central location - for example a group of IRC channels or a group of websites. Again, unless it's going through a central trusted domain, it's hard to determine the authenticity of the peer.
4) You could use some kind of nmap style discovery algorithm that searches through subnets for appropriate protocols. The problem with this approach is it's slow and it's likely to attract attention from things like firewalls etc.
5) This is a variation of 3) you could allow the peers to advertise their own information on a website, then instead of having to look for the information in a suitable location (a specific website, or group of websites), you can let google's search algorithm find it, and do the discovery for you, however you could imagine that this may take a few days for google to cache the website data with information on the peers. Also again, it would be upto you to provide some way to verify the authenticity of the advertised data.
6) If you are interested in an exclusive p2p network that locks out certain people (for example, you might want to have a file sharing network and you don't want law enforcement to be able to access it, or MPIAA), then you could use 2) and then have a referral system where you require that the initial connection provide the referrer's ip address, and then the service could connect to the referrers ip address and ask the referrer if they did indeed refer the referee.
That's all I can think of currently, but if anyone comes up with any other ways to do this, i would be very interested.