Array ( [0] => {{Short description|Hash based data structure}} [1] => [4] => '''Kademlia''' is a [[distributed hash table]] for decentralized [[peer-to-peer]] [[computer network]]s designed by Petar Maymounkov and David Mazières in 2002.{{Cite web |last=Maymounkov |first=Petar |last2=Mazieres |first2=David |title=Kademlia: A Peer-to-peer Information System Based on the XOR Metric |url=https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf |access-date=2023-12-28 |website=pdos.csail.mit.edu}}{{cite web|url=http://www.scs.stanford.edu/~dm/home/papers/|title=Papers by David Mazières|website=www.scs.stanford.edu}} It specifies the structure of the network and the exchange of information through [[node (networking)|node]] lookups. Kademlia nodes communicate among themselves using [[User Datagram Protocol|UDP]]. A virtual or [[overlay network]] is formed by the participant nodes. Each node is identified by a number or ''node ID''. The ''node ID'' serves not only as identification, but the Kademlia algorithm uses the ''node ID'' to locate values (usually file [[Hash function|hashes]] or keywords). [5] => [6] => In order to look up the value associated with a given key, the algorithm explores the network in several steps. Each step will find nodes that are closer to the key until the contacted node returns the value or no more closer nodes are found. This is very efficient: like many other {{tooltip|2=Distributed Hash Table|DHT}}s, Kademlia contacts only [[Big O notation|O(\log n)]] nodes during the search out of a total of n nodes in the system. [7] => [8] => Further advantages are found particularly in the decentralized structure, which increases the resistance against a [[denial-of-service attack]]. Even if a whole set of nodes is flooded, this will have limited effect on network availability, since the network will recover itself by knitting the network around these "holes". [9] => [10] => [[I2P]]'s implementation of Kademlia is modified to mitigate Kademlia's vulnerabilities, such as [[Sybil attack]]s.{{cite web |title=The Network Database - I2P |url=https://geti2p.net/en/docs/how/network-database#threat |website=geti2p.net}} [11] => [12] => == System details == [13] => Peer-to-peer networks are made of nodes, by design. The protocols that these nodes use to communicate, and locate information, have become more efficient over time. The first generation peer-to-peer file sharing networks, such as [[Napster]], relied on a central database to co-ordinate lookups on the network. Second generation peer-to-peer networks, such as [[Gnutella]], used flooding to locate files, searching every node on the network. Third generation peer-to-peer networks, such as [[Bittorrent]], use [[distributed hash table]]s to look up files in the network. ''Distributed hash tables'' store resource '''locations''' throughout the network. [14] => [15] => Kademlia uses a "distance" calculation between two nodes. This distance is computed as the ''[[exclusive or|exclusive or (XOR)]]'' of the two node IDs, taking the result as an unsigned [[integer|integer number]]. Keys and node IDs have the same format and length, so distance can be calculated among them in exactly the same way. The node ID is typically a large random number that is chosen with the goal of being unique for a particular node (see [[Universally unique identifier|UUID]]). It can and does happen that geographically far nodes – from Germany and Australia, for instance – can be "neighbors" if they have chosen similar random node IDs. [16] => [17] => ''XOR'' was chosen because it acts as a [[Metric (mathematics)|distance function]] between all the node IDs. Specifically: [18] => * the distance between a node and itself is zero [19] => * it is symmetric: the "distances" calculated from A to B and from B to A are the same [20] => * it follows the [[triangle inequality]]: given A, B and C are [[Vertex (geometry)|vertices]] (points) of a triangle, then the distance from A to B is shorter than (or equal to) the sum of both the distance from A to C and the distance from C to B. [21] => [22] => These three conditions are enough to ensure that ''XOR'' captures all of the essential, important features of a "real" distance function, while being cheap and simple to calculate. [23] => [24] => Each Kademlia search iteration comes one bit closer to the target. A '''basic''' Kademlia search algorithm has complexity of ''{{math|O(log2 (n))}}'', that means for network with 2^n nodes it will take '''at most''' n steps to find that node. [25] => [26] => === Fixed-size routing tables === [27] => {{hatnote|This section is simplified to use a single [[bit]]; see [[#Accelerated lookups]] for more information on real routing tables.}} [28] => [29] => Fixed-size routing tables were presented in the pre-proceedings version of the original paper{{Cite web |last=Maymounkov |first=Petar |last2=Mazieres |first2=David |title=Kademlia: A Peer-to-peer Information System Based on the XOR Metric |url=https://www.scs.stanford.edu/~dm/home/papers/kpos.pdf |access-date=2023-12-28 |website=Stanford Secure Computer Systems Group}} and are used in the later version only for some mathematical proofs. An actual Kademlia implementation does not have a fixed-size routing table, but a dynamically sized one. [30] => [31] => Kademlia routing tables consist of a ''list'' for each bit of the node ID (e.g. if a node ID consists of 128 bits, a node will keep 128 such ''lists''.) Every entry in a ''list'' holds the necessary data to locate another node. The data in each ''list'' entry is typically the ''IP address'', ''port'', and ''node ID'' of another node. Every ''list'' corresponds to a specific distance from the node. Nodes that can go in the nth ''list'' must have a differing nth bit from the node's ID; the first n-1 bits of the candidate ID must match those of the node's ID. This means that it is very easy to populate the first ''list'' as 1/2 of the nodes in the network are far away candidates. The next ''list'' can use only 1/4 of the nodes in the network (one bit closer than the first), etc. [32] => [33] => With an ID of 128 bits, every node in the network will classify other nodes in one of 128 different distances, one specific distance per bit. [34] => [35] => As nodes are encountered on the network, they are added to the ''lists''. This includes store and retrieval operations and even helping other nodes to find a key. Every node encountered will be considered for inclusion in the ''lists''. Therefore, the knowledge that a node has of the network is very dynamic. This keeps the network constantly updated and adds resilience to failures or attacks. [36] => [37] => In the Kademlia literature, the ''lists'' are referred to as ''k-buckets''. ''k'' is a system wide number, like 20. Every ''k''-bucket is a ''list'' having up to ''k'' entries inside; i.e. for a network with k=20, each node will have ''lists'' containing up to 20 nodes for a particular bit (a particular distance from itself). [38] => [39] => Since the possible nodes for each ''k-bucket'' decreases quickly (because there will be very few nodes that are that close), the lower bit ''k-buckets'' will fully map all nodes in that section of the network. Since the quantity of possible IDs is much larger than any node population can ever be, some of the ''k''-buckets corresponding to very short distances will remain empty. [40] => [41] => [[File:Dht example SVG.svg|thumb|420px|Network partition for node '''110''']] [42] => [43] => Consider the simple network to the right. The network size is 2^3 or eight maximum keys and nodes. There are seven nodes participating; the small circles at the bottom. The node under consideration is node six (binary 110) in black. There are three ''k-buckets'' for each node in this network. Nodes zero, one and two (binary 000, 001, and 010) are candidates for the farthest ''k-bucket''. Node three (binary 011, not shown) is not participating in the network. In the middle ''k-bucket'', nodes four and five (binary 100 and 101) are placed. Finally, the third ''k-bucket'' can only contain node seven (binary 111). Each of the three ''k-buckets'' are enclosed in a gray circle. If the size of the ''k-bucket'' was two, then the farthest ''2-bucket'' can only contain two of the three nodes. For example, if node six has node one and two in the farthest 2-bucket, it would have to request a node ID lookup to these nodes to find the location (ip address) of node zero. Each node ''knows'' its neighbourhood well and has contact with a few nodes far away which can help locate other nodes far away. [44] => [45] => It is known that nodes that have been connected for a long time in a network will probably remain connected for a long time in the future.Stefan Saroiu, P. Krishna Gummadi and Steven [46] => D. Gribble. A Measurement Study of Peer-to-Peer File Sharing Systems. Technical Report UW-CSE-01-06-02, University of Washington, Department of Computer Science and Engineering, July 2001.Daniel Stutzbach and Reza Rejaie. [http://www.barsoom.org/papers/imc-2006-churn.pdf Understanding Churn in Peer-to-Peer Networks] Section 5.5 Uptime Predictability, Internet Measurement Conference, Rio de Janeiro, October, 2006. Because of this statistical distribution, Kademlia selects long connected nodes to remain stored in the k-buckets. This increases the number of known valid nodes at some time in the future and provides for a more stable network. [47] => [48] => When a ''k-bucket'' is full and a new node is discovered for that ''k-bucket'', the least recently seen node in the ''k-bucket'' is PINGed. If the node is found to be still alive, the new node is placed in a secondary list, a replacement cache. The replacement cache is used only if a node in the ''k-bucket'' stops responding. In other words: new nodes are used only when older nodes disappear. [49] => [50] => === Protocol messages === [51] => Kademlia has four messages. [52] => * PING — Used to verify that a node is still alive. [53] => * STORE — Stores a (key, value) pair in one node. [54] => * FIND_NODE — The recipient of the request will return the k nodes in its own buckets that are the closest ones to the requested key. [55] => * FIND_VALUE — Same as FIND_NODE, but if the recipient of the request has the requested key in its store, it will return the corresponding value. [56] => [57] => Each [[Remote procedure call|RPC]] message includes a random value from the initiator. This ensures that when the response is received it corresponds to the request previously sent (see [[magic cookie]]). [58] => [59] => === Locating nodes === [60] => Node lookups can proceed asynchronously. The quantity of simultaneous lookups is denoted by α and is typically three. A node initiates a FIND_NODE request by querying to the α nodes in its own ''k-buckets'' that are the closest ones to the desired key. When these recipient nodes receive the request, they will look in their ''k-buckets'' and return the ''k'' closest nodes to the desired key that they know. The requester will update a results list with the results (node IDs) it receives, keeping the ''k'' best ones (the ''k'' nodes that are closer to the searched key) that respond to queries. Then the requester will select these ''k'' best results and issue the request to them, and iterate this process again and again. Because every node has a better knowledge of its own surroundings than any other node has, the received results will be other nodes that are every time closer and closer to the searched key. The iterations continue until no nodes are returned that are closer than the best previous results. When the iterations stop, the best k nodes in the results list are the ones in the whole network that are the closest to the desired key. [61] => [62] => The node information can be augmented with [[Round-trip delay time|round trip times]], or RTT. This information will be used to choose a time-out specific for every consulted node. When a query times out, another query can be initiated, never surpassing α queries at the same time. [63] => [64] => === Locating resources === [65] => Information is located by mapping it to a key. A [[Hash function|hash]] is typically used for the map. The storer nodes will have information due to a previous STORE message. Locating a value follows the same procedure as locating the closest nodes to a key, except the search terminates when a node has the requested value in its store and returns this value. [66] => [67] => The values are stored at several nodes (k of them) to allow for nodes to come and go and still have the value available in some node. Periodically, a node that stores a value will explore the network to find the k nodes that are close to the key value and replicate the value onto them. This compensates for disappeared nodes. [68] => [69] => Also, for popular values that might have many requests, the load in the storer nodes is diminished by having a retriever store this value in some node near, but outside of, the k closest ones. This new storing is called a cache. In this way the value is stored farther and farther away from the key, depending on the quantity of requests. This allows popular searches to find a storer more quickly. Because the value is returned from nodes farther away from the key, this alleviates possible "hot spots". Caching nodes will drop the value after a certain time depending on their distance from the key. [70] => [71] => Some implementations (e.g. [[Kad network|Kad]]) have neither replication nor caching. The purpose of this is to remove old information quickly from the system. The node that is providing the file will periodically refresh the information onto the network (perform FIND_NODE and STORE messages). When all of the nodes having the file go offline, nobody will be refreshing its values (sources and keywords) and the information will eventually disappear from the network. [72] => [73] => === Joining the network === [74] => A node that would like to join the net must first go through a [[Bootstrapping node|bootstrap]] process. In this phase, the joining node needs to know the [[IP address]] and port of another node—a bootstrap node (obtained from the user, or from a stored list)—that is already participating in the Kademlia network. If the joining node has not yet participated in the network it computes a [[randomness|random]] ID number, which by virtue of being a very large random number is extremely likely not to be already assigned to any other node. It uses this ID until leaving the network. [75] => [76] => The joining node inserts the bootstrap node into one of its ''k-buckets''. The joining node then performs a node lookup of its own ID against the bootstrap node (the only other node it knows). The "self-lookup" will populate other nodes' ''k-buckets'' with the new node ID, and will populate the joining node's ''k-buckets'' with the nodes in the path between it and the bootstrap node. After this, the joining node refreshes all ''k-buckets'' further away than the ''k-bucket'' the bootstrap node falls in. This refresh is just a lookup of a random key that is within that ''k-bucket'' range. [77] => [78] => Initially, nodes have one ''k-bucket''. When the ''k-bucket'' becomes full, it can be split. The split occurs if the range of nodes in the ''k-bucket'' spans the node's own id (values to the left and right in a binary tree). Kademlia relaxes even this rule for the one "closest nodes" ''k-bucket'', because typically one single bucket will correspond to the distance where all the nodes that are the closest to this node are, they may be more than ''k'', and we want it to know them all. It may turn out that a highly unbalanced binary sub-tree exists near the node. If ''k'' is 20, and there are 21+ nodes with a prefix "xxx0011....." and the new node is "xxx0000''11001''", the new node can contain multiple ''k-buckets'' for the other 21+ nodes. This is to guarantee that the network knows about all nodes in the closest region. [79] => [80] => === Accelerated lookups === [81] => Kademlia uses an ''[[exclusive or|XOR]] [[metric (mathematics)|metric]]'' to define distance. Two node IDs or a node ID and a key are XORed and the result is the distance between them. For each bit, the XOR function returns zero if the two bits are equal and one if the two bits are different. Distances in the XOR metric satisfy the [[triangle inequality]]: given A, B and C are [[Vertex (geometry)|vertices]] (points) of a triangle, then the distance from A to B is shorter than (or equal to) the sum of the distances from A to C and from C to B. [82] => [83] => The ''XOR metric'' allows Kademlia to extend routing tables beyond single bits. Groups of bits can be placed in ''k-buckets''. The group of bits are termed a prefix. For an ''m-bit'' prefix, there will be 2m-1 ''k-buckets''. The missing ''k-bucket'' is a further extension of the routing tree that contains the node ID. An ''m-bit'' prefix reduces the maximum number of lookups from ''log2 n'' to ''log2m n''. These are '''maximum''' values and the average value will be far less, increasing the chance of finding a node in a ''k-bucket'' that shares more bits than just the prefix with the target key. [84] => [85] => Nodes can use mixtures of prefixes in their routing table, such as the [[Kad Network]] used by [[eMule]]. {{Citation needed|date=January 2010}} The Kademlia network could even be heterogeneous in routing table implementations, at the expense of complicating the analysis of lookups. [86] => [87] => == Academic significance == [88] => While the XOR metric is not needed to understand Kademlia, it is critical in the analysis of the protocol. The XOR arithmetic forms an [[abelian group]] allowing closed analysis. Other DHT protocols and algorithms require [[Computer simulation|simulation]] or complicated formal analysis in order to predict network behavior and correctness. Using groups of bits as routing information also simplifies the algorithms. [89] => [90] => == Mathematical analysis of the algorithm == [91] => [92] => To analyze the algorithm, consider a Kademlia network of n nodes with IDs x_1, \ldots, x_n, each of which is a string of length d that consists of only ones and zeros. It can be modeled as a [[trie]], in which each leaf represents a node, and the labeled path from the root to a leaf represents its ID. For a node x \in \{x_1, \ldots, x_n\}, let \mathcal D_i(x) be the set of nodes (IDs) that share a prefix with x of length d - i. Then filling the i-th bucket of x can be modeled as adding pointers from the leaf x to k leaves (IDs) chosen uniformly at random from \mathcal D_i(x). Thus routing can be seen as jumping among the leaves along these pointers such that each step goes towards the target ID as much as possible, i.e., in a greedy way. [93] => [94] => Let T_{xy} be number of jumps needed to go from the leaf x to a target ID y. [95] => Assuming that x_1, \ldots, x_n are chosen deterministically from \{0,1\}^d, [96] => it has been proved that [97] => :\sup_{x_1,\ldots, x_n} \, \sup_{x \in \{x_1,\ldots, x_n\}} \, \sup_{y \in \{0,1\}^d} \mathbb E[T_{xy}] \le (1+o(1)) \frac{\log n}{H_k} , [98] => where H_k is the k-th [[harmonic number]]. Since H_k/\log k \to 1 as k \to \infty, when k is large \mathbb E T_{xy} is bounded from above by about \log_k n, however the IDs and the target are chosen.{{Cite journal |doi= 10.1007/978-3-642-45030-3_66 |volume= 8283 |pages= 711–721 |series= Lecture Notes in Computer Science |year= 2013 |last1= Cai |first1= X. S. |last2 = Devroye |journal= Algorithms and Computation |first2= L. |isbn= 978-3-642-45029-7 |title = A Probabilistic Analysis of Kademlia Networks|arxiv= 1309.5866 |s2cid= 6068991 }} This justifies the intuition that in Kademlia only O(\log n) nodes are contacted in searching for a target node. [99] => [100] => To make the model closer to real Kademlia networks, x_1, \ldots, x_n can also be assumed to be chosen uniformly at random without replacement from \{0,1\}^d. Then it can be proved that for all x \in \{x_1, \ldots, x_n\} and y \in \{0,1\}^d, [101] => : [102] => \begin{align} [103] => & T_{xy} \xrightarrow{p} \frac{\log n}{c_k},\\ [104] => & \mathbb E[T_{xy}] \to \frac{\log n}{c_k}, [105] => \end{align} [106] => [107] => where c_k is a constant depending only on k with c_k/H_k \to 1 as k \to \infty. Thus for k large, \mathbb E T_{xy}/\log_k n converges to a constant close 1. This implies that the number of nodes need to be contact in searching for a target node is actually \Theta(\log n) on average.{{cite journal|last1=Cai|first1=Xing Shi|last2=Devroye|first2=Luc|title=The Analysis of Kademlia for Random IDs|journal=Internet Mathematics|year=2015|pages=1–16|issn=1542-7951|doi=10.1080/15427951.2015.1051674|volume=11|issue=6 |arxiv=1402.1191|s2cid=16547375 }} [108] => [109] => == Use in file sharing networks == [110] => Kademlia is used in [[file sharing]] networks. By making Kademlia keyword searches, one can find information in the file-sharing network so it can be downloaded. [111] => Since there is no central instance to store an index of existing files, this task is divided evenly among all clients: If a node wants to share a file, it processes the contents of the file, calculating from it a number ([[hash function|hash]]) that will identify this file within the file-sharing network. Since file hashes and node IDs have the same length, the client can use the XOR distance function to search for several nodes whose ID is close to the hash, and instructs those nodes to store the publisher's IP address in an implementation-defined manner. Nodes with IDs closest to the file hash will therefore have a list of IP addresses of peers/publishers of this file, from which a client may in an implementation-defined manner download the file. [112] => [113] => Clients that wish to download the file from this publisher do not have to know the publisher's IP address (there can be many publishers), but only the hash of the file. A searching client will use Kademlia to search the network for the node whose ID has the smallest distance to the file hash, then will retrieve the sources list that is stored in that node. [114] => [115] => Since a key can correspond to many values, e.g. many sources of the same file, every storing node may have different information. Then, the sources are requested from all k nodes close to the key, k being the size of the bucket. [116] => [117] => The file hash is usually obtained from a specially formed Internet [[Magnet URI scheme|magnet link]] found elsewhere, or included within an indexing file obtained from other sources. [118] => [119] => Filename searches are implemented using [[Index term|keywords]]. The filename is divided into its constituent words. Each of these keywords is hashed and stored in the network, together with the corresponding filename and file hash. A search involves choosing one of the keywords, contacting the node with an ID closest to that keyword hash, and retrieving the list of filenames that contain the keyword. Since every filename in the list has its hash attached, the chosen file can then be obtained in the normal way. [120] => [121] => == Implementations == [122] => [123] => === Networks === [124] => [125] => Public networks using the Kademlia [[algorithm]] (these [[Computer network|network]]s are incompatible with one another): [126] => * [[I2P]]: an anonymous [[overlay network]] layer.{{cite web |url=https://geti2p.net/en/about/intro |title=Intro - I2P |website=geti2p.net}} [127] => * [[Kad network]]: developed originally by the [[eMule]] community to replace the server-based architecture of the [[eDonkey network]]. [128] => * [[Ethereum]]: the node discovery protocol in the Ethereum blockchain network stack is based on a slightly modified implementation of Kademlia.{{cite web |url=https://github.com/ethereum/wiki |title=GitHub - ethereum/wiki: The Ethereum Wiki. |date=25 March 2019 |via=GitHub}} [129] => * [[Overnet]]: With KadC a C library for handling its Kademlia is available. (development of Overnet is discontinued) [130] => [131] => * [[Mainline DHT]]: a DHT for [[BitTorrent]] based on an implementation of the Kademlia algorithm, for trackerless torrents. [132] => * [[Osiris (software)|Osiris]] (all version): used to manage distributed and anonymous web portal. [133] => * [[Retroshare]]: F2F decentralised communication platform with secure VOIP, instant messaging, file transfer etc. [134] => * [[Tox (protocol)|Tox]]: a fully distributed messaging, VoIP and video chat platform [135] => * [[Gnutella]] DHT: originally by [[LimeWire]]{{cite web |url=http://www.slyck.com/story1235.html |title=Slyck News - LimeWire Regains Top Download.com Position |website=www.slyck.com |access-date=2007-06-20 |archive-date=2019-01-19 |archive-url=https://web.archive.org/web/20190119121353/http://www.slyck.com/story1235.html |url-status=dead }}{{cite web |url=http://wiki.limewire.org/index.php?title=Mojito |archive-url=https://web.archive.org/web/20090217070609/http://wiki.limewire.org/index.php?title=Mojito |title=Mojito - LimeWire |archive-date=17 February 2009 |website=wiki.limewire.org}} to augment the Gnutella protocol for finding alternate file locations, now in use by other gnutella clients.{{Cite web |url=https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/ChangeLog |title=Gtk-gnutella changelog |website=sourceforge.net |archive-url=https://web.archive.org/web/20110723210536/https://gtk-gnutella.svn.sourceforge.net/svnroot/gtk-gnutella/trunk/gtk-gnutella/ChangeLog |archive-date=23 July 2011 |url-status=dead |access-date=23 January 2010}} [136] => * [[IPFS]]: a peer-to-peer distributed filesystem based on libp2p.{{cite web |url=https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf |title=IPFS Paper|website=[[GitHub]] }} [137] => [138] => * [[TeleHash]]: a mesh networking protocol that uses Kademlia to resolve direct connections between parties.{{cite web |url=http://redecentralize.org/interviews/2013/10/17/07-jeremie-telehash.html |title=#7: Jeremie Miller - TeleHash |access-date=2016-03-12}} [139] => * iMule: [[file sharing]] [[utility software]] for [[I2P]]. [140] => * [[OpenDHT]]: library providing an implementation of Kademlia, used by [[Jami (software)|Jami]] and others.{{cite web |url=https://github.com/savoirfairelinux/opendht/wiki |title=Home |department=OpenDHT Wiki |website=[[GitHub]] |publisher=[[Savoir-faire Linux]] |access-date=2021-03-19}} [141] => * [[GNUnet]]: alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Uses randomized version of Kademlia called R5N.{{cite web |url=https://git.gnunet.org/bibliography.git/plain/docs/nss2011.pdf |title=R5N: Randomized Recursive Routing for Restricted-Route Networks}} [142] => * [[Dat (software)|Dat]]: a peer-to-peer file sharing tool based{{Citation needed|date=May 2022}}{{clarify|neither Dat article, not the Hypercore Protocol ref below mention each other - so how do we know one is based on the other?|date=May 2022}} on the Hypercore Protocol.{{cite web |url=https://hypercore-protocol.org/ |title=Hypercore Protocol}}{{dead link|date=December 2023}} [143] => [144] => == See also == [145] => * [[Content-addressable network]] [146] => * [[Chord (peer-to-peer)]] [147] => * [[Tapestry (DHT)]] [148] => * [[Pastry (DHT)]] [149] => * [[Koorde]] [150] => [151] => == References == [152] => {{reflist|30em}} [153] => [154] => == External links == [155] => * [http://xlattice.sourceforge.net/components/protocol/kademlia/specs.html Xlattice projects] Kademlia Specification and definitions. [156] => [157] => {{EDonkey}} [158] => [159] => [[Category:Computer-related introductions in 2002]] [160] => [[Category:Distributed data storage]] [161] => [[Category:Hash-based data structures]] [162] => [[Category:Distributed data structures]] [163] => [[Category:File sharing]] [164] => [[Category:Network architecture]] [165] => [[Category:Hashing]] [166] => [[Category:Routing]] [167] => [[Category:Key-based routing]] [168] => [[Category:Overlay networks]] [] => )
good wiki

Kademlia

Kademlia is a distributed hash table for decentralized peer-to-peer computer networks designed by Petar Maymounkov and David Mazières in 2002. It specifies the structure of the network and the exchange of information through node lookups.

More about us

About

Expert Team

Vivamus eget neque lacus. Pellentesque egauris ex.

Award winning agency

Lorem ipsum, dolor sit amet consectetur elitorceat .

10 Year Exp.

Pellen tesque eget, mauris lorem iupsum neque lacus.

You might be interested in

Algorithm

An algorithm is a mathematical or logical formula designed to solve a specific problem or complete a specific task.

GitHub

GitHub is a web-based platform used for version control and collaboration in software development projects.

Integer

An integer is a number that can be written without a fractional or decimal component.

Peer-to-peer

Peer-to-peer (P2P) refers to a decentralized form of computer networking and software architecture that allows direct communication and file sharing between individual computers or devices without the need for a central server.