In my knowledge, bitcoin is a p2p protocol and a p2p protocol must have a dedicated central server. But it is said that bitcoin is decentralized.
Back in 2009 we relied on IRC to bootstrap the network, so every node would connect to Freenode (later LFnet) and would join a channel. Their nicknames were their encoded public IP address.
Nowadays the Bitcoin Core client, and many other implementations, rely on DNS seeds. DNS seeds are special DNS servers that are configured to return a number of randomly selected nodes from the network. The operators of the DNS seeds also run crawlers to enumerate the publicly reachable nodes that are to be returned by the seeds.
The seeds that are currently included in the Bitcoin Core client are:
bitcoin.sipa.be
dnsseed.bluematt.me
dnsseed.bitcoin.dashjr.org
seed.bitcoinstats.com
bitseed.xf2.org
bitcoin.jonasschnelli.ch
If you send a request to any of these servers they will return a number of random IPs that are known to run Bitcoin on port 8333:
dig seed.bitcoinstats.com +short
71.19.155.244
173.254.232.51
45.79.97.30
198.252.112.64
35.128.8.141
108.17.18.165
98.208.76.134
8.29.28.12
52.62.2.124
96.234.214.85
47.89.24.56
212.164.215.159
52.62.42.229
68.52.96.191
115.66.205.171
24.250.16.39
201.43.160.155
5.3.253.18
100.40.179.172
50.135.169.181
186.149.249.18
101.201.44.207
96.35.97.46
124.188.118.196
82.8.4.79
Besides the DNS seeds, the Core client also has a static list of IPs to try first and it will cache any previously contacted peers in a local database in order to reconnect without having to query the DNS seeds.
(Disclaimer: I am the operator of one of the DNS seeds)
Related
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?
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.
I was curious as to why one client site on a shared server was performing very poorly and I wanted to know if there was a way to find out how many other sites were being hosted on the same server. I found this reverse IP lookup site:
http://reverseip.domaintools.com/
that claims the client's site IP is also being used by 3000+ other sites. I did a quick survey of other clients' sites and this is more than twice the next closest, most being in the 800 - 1500 range.
Does this mean that there are 3000+ sites being hosted on one server, or could there still be multiple servers sharing an IP? Basically I want to know if this is the main likely reason the site is slow.
On public internet, sharing the same IP address does not mean sharing the same physical server. Here are the ways of sharing an IP, and yet processing on different physical server:
Most often, the public IP addresses are the interfaced by a Load Balancer, or a Reverse Proxy, or a Gateway. This device then routes (technically proxies) the connection to one of the physical servers running behind them. All these are within the firewall/network/data_cente of the "serving" organization.
Unless designed (or ill-designed) to reveal information about the internal IP addresses, there is no way to figure out the IP address of physical device that actually processed the request.
Anycast allows you to have the same IP address being available at different geographical locations. Look at Google's DNS servers (IP address 8.8.8.8). Such services are anycasted, to serve from the nearest geo-location.
This is also true from server's perspective. A server does not necessarily know the "original" IP address from where the request initiated. Most often, we are proxied, and/or NAT'ed by routers and other devices at our home and offices. After all, there are only so many public IP addresses available (at least IPv4), and we cannot have one public IP address for each device :) .
Closing statement: The server and the client only know the ingress/egress points of each other's network. Beyond that, they have no idea of the internal IP addresses of the physical devices.
Yes, it can very well mean that. It is very common, and is the only way companies selling you hosting for pennies can even approach turning a profit.
It is done with virtual hosting support in the web server. This relies on DNS and the browser / client providing the referrer URL to the server as part of the HTTP request. The HTTP server then knows who the client thinks he is requesting a URI from, and maps the request to that site tree. Those trees often sit on the same disk, though the sites may be jailed or virtualized.
I've seen numbers higher than 3000, for example.
If you want better, you have to move to a higher quality provider, and/or obtain your own IP addresses.
I'm trying to understand how can a magnetic link work, as I've read they use DHT and PEX to get the peers, but if I'm a new node in the network how can I find peers with only the hash of the file?! Doesn't it always require a link to a known host?
Thanks
The bittorrent DHT can be bootstrapped in many ways. It just needs the IP and Port of any other reachable DHT node out there.
Current clients generally use several of the following strategies:
bootstrap from a cache of long-lived nodes from a previous session
use a DNS A/AAAA record mapping to a known node (e.g. router.bittorrent.com or dht.transmissionbt.com) with a known port
use a node embedded in a .torrent file
retrieve the DHT port from a bittorrent client over a bittorrent connection established through other means, e.g. a conventional tracker.
If a peer is embedded in a magnet link one can also piggyback a DHT bootstrap on that through the port message
multicast neighbor discovery via LSD
cross-chatter from the IPv4 to the IPv6 DHTs and vice versa (if needed)
Other ways such as user-configurable bootstrap lists, DNS SRV records round-robin mapping to live nodes or - should everything else fail - adding the IP of your friend(s) manually work.
Once a node has joined the network the first strategy mentioned above will kick in and it is unlikely that it will have to bootstrap again.
So while most implementations rely on a single/few points of entry into the network for convenience, the protocol itself is flexible enough to decentralize the points of entry too.
Just for emphasis: Any node in the DHT can be used to join the network. Dedicated bootstrap nodes are an implementation detail, not part of the protocol, and could be replaced by other discovery mechanisms if necessary.
Short Question :
Since DNS is anycast, is there any way for a DNS Server to know the "first" source DNS Query originated from?
Long Question :
I've developed a custom DynDNS server using PowerDNS, I want to feed it information via web interface by users. I want the web interface to update records for each user "based on IP".
So when the DNS Server gets requests, If it could determine the source IP, it'd be easy to return records associated with that IP.
As long as I tested, the DNS Server can only know the "last" node IP on the DNS chain, not the source. Is there any way?
Regards
Google and Yahoo! submitted a draft (draft-vandergaast-edns-client-ip-01) to the IETF DNS Extensions Working Group that proposed a new EDNS0 option within DNS requests that recursive servers could use to indicate their own client's IP address to the upstream authoritative server.
The intent was to theoretically optimise the use of Content Delivery Networks by ensuring that the web server addresses returned were based on the end user's IP address, rather than on the address of the end user's DNS server.
The idea was not well received and wasn't accepted by the working group because it intentionally broke the caching layer of the DNS, and the draft has subsequently expired.
UPDATE - a variation on this has subsequently been published as RFC 7871.
Perhaps you have control of the software performing the lookup? If so, you could include the IP address as part of the request, e.g.
23-34-45-56.www.example.com
to which your custom-written server replies
23-34-45-56.www.example.com 1800 CNAME www-europe.example.com
or
23-34-45-56.www.example.com 300 A 34.45.56.67
etc.
If the client is a web browser, complications arise due to NAT, HTTP proxies, and the inability to query host interface addresses directly from Javascript. However, you might be able to do an AJAX-style lookup to a what's-my-ip service, which understands X-Forwarded-For.
Long answer to Short Question :
DNS is not anycast. Some content DNS server owners use anycasting to distribute servers in multiple physical locations around the world, but the DNS/UDP and DNS/TCP protocols themselves are not anycast. The notion simply doesn't exist at that protocol layer.
Short answer to Long Question :
No.
Expansion
As noted, there's nothing in the DNS protocol for this. Moreover, the relationship between front-end and back-end transactions at a caching resolving proxy DNS server is not one-to-one.
You'll have to use whatever client differentiation mechanisms exist in the actual service protocol that you're using, instead of putting your client differentiation in the name→IP address lookup mechanism. Client differentiation for other services doesn't belong in name→IP address lookup, anyway. Such lookup is common to multiple protocols, for starters. Use the mechanisms of whatever actual service protocol is being used by the clients who are communicating with your servers.