I am writing a decentralized chat application using nodejs, expressjs, angularjs, socket.io and ipfs.I am using libp2p to form the nodes that will communicate with each other over an open connection. Libp2p is a networking stack modularized out of IPFS project.
Libp2p allows me to build nodes which are capable of hosting a swarm or listening/ dialing to one. I have developed to the point where several nodes can communicate with each other via inputs in angularjs (supplemented by socket.io) webpage but their IP addresses and tcp ports need to be hard coded.
The problem I am facing is, if an unknown number of users join this system and set up their nodes, how do I handle the scenario. I have done lot of research into DHT specifically into its application with torrents but am no where close to actually applying it.
I do not want to run a central system that keeps track of the users as a tracker keeps track of seeders and leachers in torrents (now somewhat redundant due to DHT)
In a centralized chat application, every time a user enters or leaves, I can send an emit event from the server to all peers using socket.io signaling the same. But the equivalent in a decentralized chat app is something I am struggling with greatly.
I need some guidance please.
You won't have to worry about that issue specifically as libp2p will handle the discovery and connection of the nodes. In the end you get a primitive for process addressing which will always dial to the process if it is accessible in the network.
I've been working recently in better documentation and tutorials for libp2p, please go to https://github.com/libp2p/js-libp2p/tree/master/examples and https://github.com/libp2p/js-libp2p. More examples to come next week, including Peer Routing + Content Routing (aka DHT).
Cheers!
I'm having an issue with the startup speed of a torrent download.
So I have two libtorrent-based clients:
Client A(deluge) is the only client seeding a torrent. It's state is seeding, but it shows no peers yet.
Client B(an app I'm making) adds a torrent using
libtorrent_session.addTorrent(...
For some reason, client B doesn't start downloading immediately. It waits a few minutes, then client A's upload speed spikes up, and the torrent downloads to B.
Why is it waiting? Does this have something to do with announce interval? If that's the case, how can I mitigate that startup time, because I need the download to start immediately.
Shouldn't it just find the peer and download the file immediately?
I'm using both a tracker, and the public DHTs.
Without detailed information/logging I can only guess.
If one of your clients is behind a NAT then the other client can't establish the connection. Thus it takes time until the NATed client learns about the IP of the reachable one.
If they use a tracker that doesn't work it can take a while until DHT startup, which might also be delayed to try the tracker first.
how can I mitigate that startup time
make sure that both clients use the same tracker, that the tracker is operational and that both listening ports are reachable from the other side.
Alternatively, the client might have a manual IP:port injection mechanism you could try.
Sorry about my English. I have a problem with webRTC. My application works correctly in the same network but in different is wrong.
Technologies that I use:
socket.io
node
coffeescript
gulp
zenserver
In this github I push my code: github/oihi08/webrtc
I dont know why the application not runs with different networks. I have uploaded to a server, I tried it and nothing. But in the same network yes.
Thank you so much!!
It sounds like you aren't using a STUN/TURN server. There are a few steps to create a connection between two devices. One of these steps is to select one or more STUN/TURN servers (like "stun:stun.l.google.com:19302" for example). This server will be used to create a connection between peers, even when there is a firewall in the way on one or both ends.
When you set up one or more STUN/TURN servers, you will see that ice candidates will start being generated. The callback function peerConnection.onicecandidate will be called for every ice candidate that is generated. When the library is done generating ice candidates, it calls the callback one more time with NULL as parameter, this flags the end of the list of candidates.
You need to get these ice candidates across to the other peer somehow, usually through the same signaling server you use to create the connection in the first place. When they arrive at the other side you need to call peerconnection.addIceCandidate.
If you do these steps, you will be able to get a proper connection, even across networks with strict NAT types.
Im trying to understand how the DHT protocol works, specially on the file-sharing-torrent world. I read many articles, but im still confused with the filename-value hash generation.
My thoughs how the dht works are the following:
Lets say im joining a p2p network and i want to share some files. For these files, hashmap keys are generated and "traveled" through the network until the nodes who are responsible for these generated keys are accessed. Then each of these nodes add in his list a record that says "the guy with the x IP address has the file that is related with the specified key.
When i search for a file, the hashmap key is generated for this file and travels the network until the node responsible for this key is found. Then this node is communicates with me and send me the IP addresses for the nodes that hosts the real data
Are my thoughs above correct??
Your thoughts are correct. This is the general idea behind DHT's.
For the first time I used a magnet link. Curious about how it works, I looked up the specs and didn't find any answers. The wiki says xt means "exact topic" and is followed by the format (btih in this case) with a SHA1 hash. I saw base32 mentioned, knowing it's 5 bits per character and 32 characters, I found it holds exactly 160bits, which is exactly the size of the SHA1.
There's no room for an IP address or anything, it's just a SHA1. So how does the BitTorrent client find the actual file? I turned on URL Snooper to see if it visits a page (using TCP) or does a lookup or the like, but nothing happened. I have no idea how the client finds peers. How does this work?
Also, what is the hash of? Is it a hash of an array of all the file hashes together? Maybe it's a hash of the actual torrent file required (stripping certain information)?
In a VM, I tried a magnet link with uTorrent (which was freshly installed) and it managed to find peers. Where did the first peer come from? It was fresh and there were no other torrents.
A BitTorrent magnet link identifies a torrent using1 a SHA-1 or truncated SHA-256 hash value known as the "infohash". This is the same value that peers (clients) use to identify torrents when communicating with trackers or other peers. A traditional .torrent file contains a data structure with two top-level keys: announce, identifying the tracker(s) to use for the download, and info, containing the filenames and hashes for the torrent. The "infohash" is the hash of the encoded info data.
Some magnet links include trackers or web seeds, but they often don't. Your client may know nothing about the torrent except for its infohash. The first thing it needs to is find other peers who are downloading the torrent. It does this using a separate peer-to-peer network2 operating a "distributed hash table" (DHT). A DHT is a big distributed index which maps torrents (identified by infohashes) to lists of peers (identified by IP address and ports) who are participating in a swarm for that torrent (uploading/downloading data or metadata).
The first time a client joins the DHT network it generates a random 160-bit ID from the same space as infohashes. It then bootstraps its connection to the DHT network using either hard-coded addresses of clients controlled by the client developer, or DHT-supporting clients previously encountered in a torrent swarm. When it wants to participate in a swarm for a given torrent, it searches the DHT network for several other clients whose IDs are as close3 as possible to the infohash. It notifies these clients that it would like to participate in the swarm, and asks them for the connection information of any peers they already know of who are participating in the swarm.
When peers are uploading/downloading a particular torrent, they try to tell each other about all of the other peers they know of that are participating in the same torrent swarm. This lets peers know of each other quickly, without subjecting a tracker or DHT to constant requests. Once you've learned of a few peers from the DHT, your client will be able to ask those peers for the connection information of yet more peers in the torrent swarm, until you have all of the peers you need.
Finally, we can ask these peers for the torrent's info metadata, containing the filenames and hash list. Once we've downloaded this information and verified that it's correct using the known infohash, we're in practically the same position as a client that started with a regular .torrent file and got a list of peers from the included tracker.
The download may begin.
1 The infohash is typically hex-encoded, but some old clients used base 32 instead. v1 (urn:btih:) uses the SHA-1 digest directly, while v2 (urn:bimh:) adds a multihash prefix to identify the hash algorithm and digest length.
2 There are two primary DHT networks: the simpler "mainline" DHT, and a more complicated protocol used by Azureus.
3 The distance is measured by XOR.
Further Reading
BEP-3: The BitTorrent Protocol Specification
BEP-52: The BitTorrent Protocol Specification v2
BEP-5: DHT Protocol
BEP-9: Extension for Peers to Send Metadata Files
BEP-10: Extension Protocol
BEP-11: Peer Exchange (PEX)
Azureus DHT Description
Peer discovery and resource discovery (files in your case) are two different things.
I am more familiar with JXTA but all peer to peer networks work on the same basic principles.
The first thing that needs to happen is peer discovery.
Peer Discovery
Most p2p networks are "seeded" networks: when first starting a peer will connect to a well-known (hard-coded) address to retrieve a list of running peers. It can be direct seeding like connecting to dht.transmissionbt.com as mentioned in another post or indirect seeding as usually done with JXTA where the peer connects to an address that only delivers a plain text list of other peers network addresses.
Once connection is established with the first (few) peer(s), the connecting peer performs a discovery of other peers (by sending requests out) and maintains a table of them. Since the number of other peers can be huge, the connecting peer only maintains part of a Distributed Hash Table (DHT) of the peers. The algorithm to determine which part of the table the connecting peer should maintain varies depending on Network. BitTorrent uses Kademlia with 160 bit identifiers/keys.
Resource Discovery
Once a few peers have been discovered by the connecting peer, the latter sends a few requests out for discovery of resources to them. Magnet links identifies those resources and are built in such a way that they are a "signature" for a resource and guarantee that they uniquely identify the requested content among all the peers.
The connecting peer will then send a discovery request for the magnet link/resource to peers around it. The DHT is built in such a way that it helps determine which peers should be asked first for the resource (read on Kademlia in Wikipedia for more).
If the requested peer does not hold the requested resource it will usually "pass on" the query to additional peers fetched from its own DHT.
The number of "hops" the query can be passed on is usually limited; 4 is an usual number with JXTA type networks.
When a peer holds the resource, it replies with its full details. The connecting peer can then connect to the peer holding the resource (directly or via a relay - I won't go into details here) and start fetching it.
Resources/Services in P2P networks are not directly attached to network addresses: they are distributed and that is the beauty of these highly scalable networks.
I was curious by the same question myself. Reading the code for transmission, I found the following in libtrnasmission/tr-dht.c:
3248: bootstrap_from_name( "dht.transmissionbt.com", 6881,
bootstrap_af(session) );
It tries that 6 times, waiting 40(!) seconds between tries. I guess you can test it by deleting the config files (~/.config/transmission on unix), and blocking all communication to dht.transmissionbt.com, and see what happens (wait 240 seconds at least).
So it appears the client has a bootstrap node built in to start with. Of course, once it has gotten into the network, it doesn't need that bootstrap node anymore.
I finally found specification. For the first time google didnt help. (wiki linked to bittorrent.com which is the main site. I Clicked the developers link, notice the bittorrent.org tab on the right then it was easy from there. Its hard finding links when you have no idea what they are labeled and many clicks away).
It seems like all torrents have a network of peers. You find peers from trackers and you keep them between sessions. The network allows you to find peers and other things. I havent read how its used with magnet links but it seems like it is undefined how a fresh client find peers. Perhaps some is baked in, or they use their home server or known trackers embeded into the client to get the first peer in the network.
When I started answering your question, I didn't realize you were asking how the magnet scheme works. Just thought you wanted to know how the parts relevant to the bittorrent protocol were generated.
The hash listed in the magnet uri is the torrent's info hash encoded in base32. The info hash is the sha1 hash of the bencoded info block of the torrent.
This python code demonstrates how it can be calculated.
I wrote a (very naive) C# implementation to test this out since I didn't have a bencoder on hand and it matches what is expected from the client.
static string CalculateInfoHash(string path)
{
// assumes info block is last entry in dictionary
var infokey = "e4:info";
var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length;
byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray();
byte[] bytes;
using (SHA1 sha1 = SHA1.Create())
bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding
return String.Join("", bytes.Select(b => b.ToString("X2")));
}
As I understand it, this hash does not include any information on how to locate the tracker, the client needs to find this out through other means (the announce url provided). This is just what distinguishes one torrent from another on the tracker.
Everything related to the bittorrent protocol still revolves around the tracker. It is still the primary means of communication among the swarm. The magnet uri scheme was not designed specifically for use by bittorrent. It's used by any P2P protocols as an alternative form of communicating. Bittorrent clients adapted to accept magnet links as another way to identify torrents that way you don't need to download .torrent files anymore. The magnet uri still needs to specify the tracker in order to locate it so the client may participate. It can contain information about other protocols but is irrelevant to the bittorrent protocol. The bittorrent protocol ultimately will not work without the trackers.
the list of peers are probably populated from the torrent that upgrades the client (e.g. there's a torrent for utorrent that upgrades it). as long as everyone's using the same client, it should be good because you have no choice but to share the upgrade.