Skip to content

DHT Network

The Distributed Hash Table (DHT) network is a core component of FuryMesh that enables decentralized peer discovery and content indexing without relying on central servers.

Overview

FuryMesh implements a Kademlia-based DHT that provides:

  • Decentralized Peer Discovery: Find other nodes in the network without central coordination
  • Content Indexing: Locate files across the network using their hash identifiers
  • Scalability: Efficiently scale to thousands of nodes with logarithmic lookup complexity
  • Resilience: Continue functioning even when nodes join or leave the network

How It Works

Node Identification

Each node in the FuryMesh network is assigned a unique 160-bit identifier (NodeID). This ID is used to determine the node's position in the DHT and its responsibility for storing specific key-value pairs.

NodeID: 3fd5ae44f2270d5e34949978d9af7d0e8e4790eb

Distance Metric

The Kademlia DHT uses an XOR-based distance metric to determine the "closeness" between two nodes:

distance(NodeA, NodeB) = NodeA.ID XOR NodeB.ID

This metric ensures that lookups converge quickly and efficiently.

Routing Table

Each node maintains a routing table organized into "k-buckets" that store contact information for other nodes. The routing table is structured to provide more detailed information about nodes that are "closer" to the local node in the XOR metric space.

K-bucket 0: Nodes with distance 2^0 to 2^1
K-bucket 1: Nodes with distance 2^1 to 2^2
...
K-bucket 159: Nodes with distance 2^159 to 2^160

Key Operations

The DHT supports four primary operations:

  1. PING: Verify if a node is still alive
  2. STORE: Store a key-value pair on a node
  3. FIND_NODE: Find the k closest nodes to a given NodeID
  4. FIND_VALUE: Retrieve a value associated with a key

Network Bootstrapping

When a new node joins the FuryMesh network, it needs to bootstrap its routing table:

  1. The node starts with a list of known bootstrap nodes (either hardcoded or from a previous session)
  2. It performs a FIND_NODE operation for its own NodeID
  3. As it receives responses, it populates its routing table
  4. It refreshes buckets that haven't been updated recently

Content Discovery

To find content in the network:

  1. A file is identified by its hash (typically SHA-1 or SHA-256)
  2. The hash is used as a key in the DHT
  3. A FIND_VALUE operation is performed to locate nodes that have information about the file
  4. Once found, direct connections can be established for file transfer

NAT Traversal

The DHT also assists with NAT traversal by:

  • Storing connection information for nodes behind NATs
  • Facilitating hole-punching techniques
  • Providing relay candidates when direct connections aren't possible

Configuration Options

FuryMesh allows customization of DHT behavior through several configuration options:

dht:
  bootstrap_nodes:
    - example.bootstrap.com:6881
    - example2.bootstrap.com:6881
  k_value: 20  # Size of k-buckets
  alpha: 3     # Number of parallel lookups
  refresh_interval: 3600  # Routing table refresh interval in seconds
  storage_ttl: 86400     # Time-to-live for stored values in seconds

Performance Considerations

The DHT is designed for efficiency:

  • Lookups complete in O(log n) steps, where n is the network size
  • Storage requirements are O(log n) per node
  • Network traffic scales logarithmically with network size

Security Considerations

While the DHT provides powerful decentralization capabilities, users should be aware of potential security considerations:

  • Sybil Attacks: Mitigated through NodeID generation requirements
  • Eclipse Attacks: Reduced by maintaining diverse routing tables
  • Privacy: Content keys are hashed, but participation in the DHT reveals some network activity

FuryMesh implements several security measures to protect against these threats while maintaining the benefits of decentralization.