BitTorrent as a node Subsystem — wraps bittorrent::Client and shares the node's DHT. More...
#include "librats/util/rats_export.h"#include "librats/node/peer_network.h"#include "librats/bittorrent/client.h"#include "librats/dht/dht.h"#include <condition_variable>#include <cstddef>#include <cstdint>#include <functional>#include <memory>#include <mutex>#include <string>Go to the source code of this file.
Classes | |
| class | librats::Bittorrent |
| struct | librats::Bittorrent::Config |
Namespaces | |
| namespace | librats |
BitTorrent as a node Subsystem — wraps bittorrent::Client and shares the node's DHT.
Attach it like any other subsystem, BEFORE start():
auto* dht = node.add_subsystem(std::make_unique<DhtDiscovery>(dht_cfg));
auto* bt = node.add_subsystem(std::make_unique<Bittorrent>(bt_cfg));
node.start();
bt->client()->add_magnet("magnet:?xt=urn:btih:…", "./downloads");
BitTorrent keeps its own transport (bittorrent::Client runs its own reactor and the swarm protocol), so this subsystem does NOT touch the node's peer mesh. What it integrates is lifecycle and the DHT: when a DhtDiscovery is also attached, the client borrows that same Kademlia node (DhtService) instead of standing one up — one routing table, one swarm. Attach Bittorrent AFTER DhtDiscovery so the borrowed client is live at start() and (thanks to reverse-order teardown) still alive through stop(). Without a DhtDiscovery the client simply runs DHT-less (trackers, PEX and manually-added peers still work).
Spider mode (the rats-search infohash crawler) lives in the DHT layer; the wrappers here delegate to whichever DHT the client ended up using.
Definition in file bittorrent.h.