DhtNode

Result of getItem: the best item found (or null), the closest token-bearing nodes, and observedSeq, the highest mutable sequence number seen across responders. Use that as the cas value for a following mutable putItem. It is null if nothing was found.

Peers found for an info-hash, plus the closest responders + their write tokens (for announce).

Result of a BEP-51 sample_infohashes query.

Our own node id (m_id). Mutable so enableSecureId can re-derive it from our IP.

Announce that we are a peer for infoHash on port to the closest nodes that gave us a token.

Ping the router nodes, pull their neighbours, then self-lookup to fill the table.

Re-derive our node id from our observed external IP per BEP-42 and (optionally) turn on the enforceNodeId admission gate. The engine calls this once it learns our external address (e.g. from a router's ip reply or the platform). The routing table is rebuilt around the new id (RoutingTable.updateNodeId).

Fetch a BEP-44 item from the DHT. This is the client port of node::get_item and its traversal. Runs a get traversal toward target, merging closer nodes from each reply, and returns the best item found (the highest-seq verified mutable item, or the immutable item) together with the closest responders and their write tokens (so a follow-up putItem can re-publish without a second lookup).

Iterative get_peers traversal toward infoHash; returns the swarm peers it found.

Periodic upkeep: the session-layer port of node::tick and dht_tracker's timers. Call on a steady cadence (libtorrent ticks the refresh timer every 5 s and the storage/token timers on slower multiples; ~30 s is a sensible single cadence here):

Store a BEP-44 item in the DHT. This is the client port of node::put_item. It runs a get→(optional cas)→put: a getItem traversal locates the closest nodes and their write tokens, then a put is fired to each. For a mutable item, the discovered highest stored sequence number is supplied as cas so a concurrent writer can't be silently clobbered (libtorrent's compare-and-swap). Returns the number of nodes the put was accepted by (a non-error reply).

Re-announce ourselves as a peer for every info-hash in infoHashes on port. A session calls this on its DHT announce interval, roughly every 15 minutes. It loops over announce. Each announce is independent, so one failure does not stop the others.

Restore known nodes from a serialize blob, re-seeding the routing table (they're added un-pinged via RoutingTable.heardAbout; the next lookup confirms them). The node id is not changed here. The constructor and enableSecureId own id continuity. The saved id is returned, so a caller can reconstruct with it.

BEP-51 client: ask host:port for a sample of the info-hashes it tracks. Returns the decoded sample (20-byte info-hashes) plus the closest nodes it pointed us at, or null on timeout/parse failure. This is the querier half; most callers only need it for DHT-wide content indexing.

Serialize the node id and the live routing-table nodes into a bencoded blob the platform can persist and pass back to restore on the next start. This is the KiteTorrent analogue of libtorrent's dht_state save (save_state, dht_settings). Only the id and (host, port) of every live node is kept; ids are re-confirmed on the next bootstrap, so a stale node simply fails to answer and is dropped.

Turn BEP-43 read-only mode on/off at runtime (dht_read_only).

Start the inbound receive loop. Responses are routed to RPC waiters; queries are answered.

Alias for maintain, named to match DhtStorage.tick and DhtTokens.