How do distributed applications (bitcoin, torrents...) find each other?

Asked

Viewed 298 times

24

How distributed/decentralized software is able to establish connection and find other machines running the same software?

In Bitcoin, for example, how do the "Full Nodes" meet each other? How does he find "another wallet" to communicate?

Some decentralized software, such as Torrent, uses an intermediary, unless mistaken are called Trackers, which allow you to find each other. They seem to act like a DNS, roughly, in order to obtain the address of those who have the downloaded file and can send you.

However, if a platform is distributed, with no central server to obtain information, how the hell can it find the others? For me, in my conception there will always be an "intermediary" to enable one to find the others, am I right? There is another way to enable "distributed application connections"?

software-architecture

1 answer

18


In the case of the Bitcoin protocol, specifically, there is no intermediary for a network client to find others to connect to. A Bitcoin client, when starting, will try to use some methods, in order, to discover other nodes in the network. These methods are as follows::

  • All nodes maintain a list of other nodes known to them, and preferentially connect to them at the start. This list contains all the nodes he’s already connected to.

    The protocol also enables a node to ask another node for information about the active nodes it knows, via the message getaddr. Customers send this message to the nodes they connect to, with the aim of increasing their list of known nodes.

    If the customer has never been online before, they still don’t have any IP addresses on their list of known nodes, so you’ll need to get one using the next method.

  • DNS queries: There is a list of domains maintained for the sole purpose of providing a list of Ips that are recognizably running Bitcoin network nodes, and these domains are embedded in Bitcoin client code.
    So it only takes a DNS query in these domains to have a list of initial nodes to connect to, and from them go increasing the local base of known nodes.
    One can see the specific part of the code where these areas are located, and section where the client makes the consultation;

  • There is also a list of IP’s of embedded Bitcoin network nodes (hardcoded) in the code, which will be used if all other methods fail. This list can be viewed in that part of the code, and is used here;
  • The user can also start your client by passing a list of IP’s of nodes that he should try to connect to initially, but in that case you would have to know the IP of at least one node that already exists.
    This is done through the parameter -addnode=<ip>. A list of available parameters can be viewed here.

Note: This response and the links to the code on Github refer to the version 0.14.2.

  • The answer is good but I think it fails to state that: there is no intermediary for one client to find another. The initial connection must connect to an address (known to the network) to request at least 1 active node. The protocol defines the option getaddr for this. After receiving at least 1 address the customer can manage the list itself. The first item in your list only occurs from the second connection and the last item is only used if the user creates or uses an alternative client to which they do not have the list of ips or dns.

  • 1

    @Lauromoraes I incremented the answer with your information.

Browser other questions tagged software-architecture

You are not signed in. Login or sign up in order to post.