I know that BitTorrent DHT can be used to coordinate torrents without the need for a tracker. Now, I would like to build a P2P network of nodes and I would prefer to avoid the hassle of developing my own discovery / signaling / handshaking / NAT traversal.
So I was wondering: is there any library (preferably nodejs) that I can use to just:
Generate an identifier on a node A.
On a node B, use A's identifier to connect to A.
Both nodes get some callback with a socket, ready to write on?
I mean, this should be somehow part of the handshaking protocol for BitTorrent, but instead of directly using the torrent protocol to send data, I would like to directly get to talk with the other node and implement my own protocol.
Is it possible?
The bittorrent DHT and the bittorrent data transfer protocol are separate things. So yes, it is possible to find other IP/Port contacts through the DHT and connect to them with a custom protocol.
Related
While learning about p2p networks I found out that P2P networks need signaling servers but can modern DHT replace the need for signaling servers? (Holepunching mainly)
A vanilla DHT that only acts as hash table can't serve that purpose but a customized implementation where the nodes support some protocol-specific extensions it is possible. E.g. in the bittorent DHT clients can instruct DHT nodes to put whatever their externally visible port is into the hash table rather than simply publishing their internal port number. This only really works for full-cone NAT.
For restricted cone or symmetric nat more complicated signalling and guessing approaches like STUN would have to be added to all DHT nodes and peers behind NATs could then initiate traversal at a particular node by publishing it as their rendezvous.
I'm working on a data sharing app using node js, the idea is to create an application that can connect peers using node-js without using any kind of central dependency i.e a signalling server or something of its kind. After a lot of research I'm always back to this diagram but it only makes sense if there is no signalling server I'm targeting LAN networks so that I don't have to deal with NAT.
To be specific, I would like some to answer these specific question
Is it possible to connect to webrtc on LAN, i.e the webrtc connection will connect using my client's ip
Is it possible to use websockets without a central server, or something like websockets
Is it possible to connect two clients on LAN using node js without using any hardcoded Ips or asking users to enter ip.
Since you are using node.js, you can very well use raw UDP (dgram) and use UDP broadcasting for device discovery - then you do not need any form of centralization required by websockets/webRTC.
The answer to all your questions is Yes!
Also, there is a lof WebRTC server that you can use them on a simple Linux box, like Janus, Kurento, etc. I've tested them and they have worked with some mischief, lol. So, run it and next read their API to exchange anything you want on their medium.
I'm not sure about Janus but the Kurento has a nodeJS client itself. Read the Local Installation and JavaScript Kurento Client.
Additionally, if you want to make a WebSocket connection, it has enabled by default configuration.
To change the port, enter this command at the final step:
npm start -- --ws_uri=ws://https://185.164.72.144/:8888/kurento --as_uri=https://185.164.72.144:6008/
I want to create peer-to-peer connections between 2 nodejs client.
using websocket (dnode)
here is the limit:
nodejs client run at 2 pc which is in different network.
they don't have static ip (192.168.1.100 && 192.168.2.200) behind NAT or firewalls
no permission to change the mapping of router.
has only static web server in public network. (can change the file by human)
can install application at pc (win)
is it possible? thanks
May be you can use PeerJS to achieve your objectives.
PeerJS simplifies WebRTC peer-to-peer data, video, and audio calls.
PeerJS wraps the browser's WebRTC implementation to provide a complete, configurable, and easy-to-use peer-to-peer connection API. Equipped with nothing but an ID, a peer can create a P2P data or media stream connection to a remote peer.
Also to broker connections, PeerJS connects to a PeerServer. Note that no peer-to-peer data goes through the server; The server acts only as a connection broker.
If by peer to peer connection, you mean direct connection between the peers (i.e., not via a server) then yes it is probably possible in theory in most cases. But I have never seen someone who has implemented the solution.
You would need to implement a NAT hole punching system for TCP connections (they are not always 100% successful because of technical constraints which can't be solved at the software layer). Then, you'd just need to implement the websocket protocol on top of this tcp connection.
If by peer to peer connection, your are ok that communication passes via a central server (with a public address), then yes it is possible too. Both peers just need to connect to the central server, and it should just transfert the traffic between both peer.
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.
If I have a torrent w/o any trackers in it, and I just started a bittorent client so I have no peers yet...how do I know who to first connect with in the DHT? It seems like I would have to know at least ONE node in the DHT to get started....
The mainline DHT bootstrap nodes are router.utorrent.com and a CNAME to it, router.bittorrent.com. Port 6881.
When a BitTorrent client connects to DHT, there is an initial place that it goes to find peers. With the original BitTorrent client, there was a url to bitorrent.com that would help get things started. I tried looking up the reference but I couldn't find it. Once you've established connections with other clients, then you can do an announce on the DHT network to find peers for the torrent you're looking for.
Here's a link to the BitTorrent specs that discuss DHT.
A trackerless torrent dictionary does
not have an "announce" key. Instead, a
trackerless torrent has a "nodes" key.
This key should be set to the K
closest nodes in the torrent
generating client's routing table.
Alternatively, the key could be set to
a known good node such as one operated
by the person generating the torrent.
Please do not automatically add
"router.bittorrent.com" to torrent
files or automatically add this node
to clients routing tables.
the graph at the bottom of this DHT monitoring project site shows
dht.transmissionbt.com
router.utorrent.com
router.bittorrent.com
as bootstrapping peers
In BiTTorrent, you have three main options:
Torrent File: some torrent files can embed nodes for you to link into the DHT with (in fact, it's recommended when making a torrent file)
Hardcoding: Some torrent clients hard code a few bootstrap nodes (like the ones mentioned by stk). These are usually run by companies and organizations with long-running servers.
PEX / Peer Conversations: You can usually ask for DHT nodes from the people you are downloading other torrents from (if your clients understand eachothers language. ie some versions are incompatible).
Transmission uses a hardcoded bootstrap node for dht if there is no other way to get peers:
bootstrap_from_name( "dht.transmissionbt.com", 6881, bootstrap_af(session) );
I guess each torrent client uses their own bootstrap node.
For the record, Deluge also uses hardcoded boostrap nodes:
dht_bootstraps = set(
lt_bootstraps.split(',')
+ [
'router.bittorrent.com:6881',
'router.utorrent.com:6881',
'router.bitcomet.com:6881',
'dht.transmissionbt.com:6881',
'dht.aelitis.com:6881',
]
)
A client can learn about other DHT-capable peers through it's interactions with them. A peer's support for DHT is advertised in it's Handshake. Once a client discovers at least one good, well-connected DHT peer, it can navigate the DHT to find more and closer DHT peers. It will remember these peers, called nodes in DHT-speak, between restarts of the software and maintain/update the list continuously while it is running. In the worse case where a client knows of no good DHT-capable peers, it will require you to download a tracker-based torrent so it can hopefully contact a few good DHT-capable peers it learns about through the tracker.
Update:
For it's initial list of DHT peers, as #Seppo points out, a torrent client can use one or more hard-coded DNS names to find the addresses for well-known peers, and it may also include a hard-coded list of peers as a final fallback as well. One limitation of DNS, however, it no port information is provided so a default port of 6881 is generally assumed whereas other means support peers operating on different ports.
Here are the primary nodes I've come across.
dht.transmissionbt.com 6881
router.bittorrent.com 6881
router.bitcomet.com 6881
dht.aelitis.com 6881
bootstrap.jami.net 4222