La page se tourne.
Le prochain chapitre arrive…
Psst… appropriez-vous votre lecture.
Polices et thèmes se trouvent dans Apparence. Vos yeux ont aussi leur mot à dire.
Le prochain chapitre arrive…
A distributed lookup system that assigns responsibility for keys across participating nodes and routes requests to the responsible node.
Vérification de la lecture vocale du navigateur…
Cette lecture est actuellement disponible en anglais. L’interface utilise la langue choisie.
Lire l’original anglais →A distributed hash table (DHT) is a distributed system that provides a lookup service similar to a hash table. Key–value pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. The main advantage of a DHT is that nodes can be added or removed with minimum work around re-distributing keys. Keys are unique identifiers which map to particular values, which in turn can be anything from addresses, to documents, to arbitrary data.
Responsibility for maintaining the mapping from keys to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. This allows a DHT to scale to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures.
DHTs form an infrastructure that can be used to build more complex services, such as anycast, cooperative web caching, distributed file systems, domain name services, instant messaging, multicast, and also peer-to-peer file sharing and content distribution systems. Notable distributed networks that use DHTs include BitTorrent's distributed tracker, the Kad network, the Storm botnet, the Tox instant messenger, Freenet, the YaCy search engine, and the InterPlanetary File System.
DHT research was originally motivated, in part, by peer-to-peer (P2P) systems such as Freenet, Gnutella, BitTorrent and Napster, which took advantage of resources distributed across the Internet to provide a single useful application. In particular, they took advantage of increased bandwidth and hard disk capacity to provide a file-sharing service.
These systems differed in how they located the data offered by their peers. Napster, the first large-scale P2P content delivery system, required a central index server: each node, upon joining, would send a list of locally held files to the server, which would perform searches and refer the queries to the nodes that held the results. This central component left the system vulnerable to attacks and lawsuits.
Gnutella and similar networks moved to a query flooding model – in essence, each search would result in a message being broadcast to every machine in the network. While avoiding a single point of failure, this method was significantly less efficient than Napster. Later versions of Gnutella clients moved to a dynamic querying model which vastly improved efficiency.
Sélectionné et remis en forme à partir de Distributed hash table, par ses contributeurs, sous CC BY-SA 4.0. Révision 1376764733. Les sections et la mise en forme ont été abrégées ; la révision liée fournit le contexte complet et l’historique des contributions. Ce texte de référence conserve sa licence. Les liens de citation supplémentaires proviennent de cette révision et n’ont pas été vérifiés indépendamment ici.