kademlia

In Kademlia, why is it recommended to have 160-bit node IDs and keys and not 128-bit?

南笙酒味 提交于 2021-01-28 02:06:01
问题 The Kademlia paper states that nodes are assigned random 160-bit IDs as well as the keys. Is this a strict restriction? Can I still go ahead and use a 128-bit keyspace if that's good enough from me? 回答1: The length was chosen because SHA1, used as hash function for the hash table keys, outputs 160bits and that was the most widely used hash function at the time. The routing algorithm itself does not require that specific length to work, all it needs is the key space being large enough to avoid

易懂分布式 | Kademlia算法

懵懂的女人 提交于 2021-01-04 15:17:52
近年来,区块链技术(部分人更愿意称之为分布式账本技术)的走红将分布式技术的概念带入大众的视野。区块链技术之所以备受追捧,一方面是其展现了一种在计算机的辅助下,人类可以以无中心、无权威、无层级的方式来进行社会协作的美妙前景;另一方面,从物理上可论证,分布式的简单协议,比中心化的复杂协议更为高效。分布式技术似乎能够在带来公平的同时,还带来效率。 要理解分布式技术并不困难,因为分布式技术并不高深,但其设计上往往巧妙得令人拍手称赞。 本文介绍一种常见而巧妙的分布式技术,Kademlia算法。 Kademlia算法是一种分布式存储及路由的算法。什么是分布式存储?试想一下,一所1000人的学校,现在学校突然决定拆掉图书馆(不设立中心化的服务器),将图书馆里所有的书都分发到每位学生手上(所有的文件分散存储在各个节点上)。即是所有的学生,共同组成了一个分布式的图书馆。 由中心图书馆到分布式图书馆 在这种场景下,有几个关键的问题需要回答。 1)关键问题 每个同学手上都分配哪些书。即如何分配存储内容到各个节点,新增/删除内容如何处理。 当你需要找到一本书,譬如《分布式算法》的时候,如何知道哪位同学手上有《分布式算法》(对1000个人挨个问一遍,“你有没有《分布式算法》?”,显然是个不经济的做法),又如何联系上这位同学。即一个节点如果想获取某个特定的文件,如何找到存储文件的节点/地址/路径。

Libp2p学习(一)

只谈情不闲聊 提交于 2021-01-03 15:46:29
Libp2p学习 参考资料:libp2p-specifications : https://github.com/libp2p/specs 持续更新ing 1. 介绍 Libp2p的实现目标是: 支持各种各样的传输方式: 传输:TCP,UDP,SCTP,UDP,uTP,QUIC,SSH,etc. 安全传输:TLS,DTLS,CurveCP,SSH 有效使用sockets(连接重用) 允许端点之间的交流可以在一个socket上复用(避免过多的握手) 允许端点之间通过一个协商过程使用多协议以及各自的版本 向后兼容 在现在的系统中可以运行 充分使用当前网络技术的能力 实现NAT转换 实现连接中继 实现加密通道 充分使用基础传输(例如原生的流复用等) 传统的7层OSI模型表征不适合libp2p。Libp2p根据协议的角色(功能)进行划分。不同的lip2p协议可以具有相同的功能,例如,bootstrap lists,mDNS,DHT discovery,PEX都进行节点发现,但他们可以同时存在甚至协同工作。而在OSI中,每一层通常都只有一个协议。 2. 基础 libp2p使用了 multiaddr ,一个自描述的地址形式,可以理解为不同协议不同地址类型的一个封装。这使得libp2p可以不透明的处理系统中的所有地址,支持网络层中的各种传输协议。 libp2p的协议是多个协议的集合

至联云讲解《IPFS之通向新的DHT》

余生颓废 提交于 2020-08-07 09:56:02
在4月末,IPFS/Filecoin团队发布了最新版的IPFS 0.5.0,这个新版本在IPFS性能和可靠性上有了极大的提高,尤其在内容发掘和路由方面。 而这些性能之所以能有如此显著的提高,主要原因是IPFS/Filecoin团队对分布式哈希表(DHT)进行了较大的改进,而分布式哈希表正是IPFS网络中处理内容发掘的根本。 在这篇文章中,我们将和大家分享IPFS/Filecoin团队是如何重新改写DHT的细节,包括团队是如何发现其中的问题、如何对解决这些问题以及如何确保研发的方案实际可行。 团队在这个过程中所取得的成果:不仅包括对系统性能的提升,还包括研发出的新产品Testground------一个可用于大规模网络测试的工具。 我们先来回顾一下什么是DHT,分布式哈希表。这个哈希表就像IPFS的目录和引导系统,帮助网络定位和搜索数据。 通常这样一个哈希表由一对对“键”-“值”组成,其中的“键”是某数据的内容标识符(CID),“值”是IPFS网路中存储这些数据的节点。 DHT表在系统中多处节点都存储着这些“键”-“值”。DHT在IPFS系统中具体的实现方案是Kademlia,Kademlia负责定位这些“键”所对应的数据存储在哪些节点上。 理论上讲,DHT应该以高效,统一的方式定位并获取用户所需的数据。但在一个急速扩张的IPFS网络中,实际情况往往比理论上复杂得多。

[转帖]分布式哈希表 (DHT) 和 P2P 技术

荒凉一梦 提交于 2020-04-21 03:32:17
分布式哈希表 (DHT) 和 P2P 技术 https: // luyuhuang.github.io/2020/03/06/dht-and-p2p.html 1. 引言 相信没有人没使用过 P2P 技术. BT 种子和磁力链接就是最常见的 P2P 技术, 使用 P2P 技术, 文件不再需要集中存储在一台服务器上, 而是分散再各个用户的节点上, 每个人都是服务的提供者, 也是服务的使用者. 这样的系统具有高可用性, 不会由于一两台机的宕机而导致整个服务不可用. 那么这样一个系统是怎样实现的, 如何做到去中心化(decentralization)和自我组织(self-organization)的呢? 这篇文章我们来讨论一下这个问题. 这篇文章先会介绍 P2P 网络的整体思路, 并引出 P2P 网络的主角 - 分布式哈希表(Distributed Hash Table, DHT); 接着会介绍两种分布式哈希表算法. 这些会让你对 P2P 技术有一个较为具体的了解. 2. P2P 网络的概述 2.1 传统 CS 网络和 P2P 网络 CS 架构即 Client-Server 架构, 由服务器和客户端组成: 服务器为服务的提供者, 客户端为服务的使用者. 我们如今使用的很多应用程序例如网盘, 视频应用, 网购平台等都是 CS 架构. 它的架构如下图所示: 当然服务器通常不是一个单点,

Is there a clearly documented consensus in plain English that describes Maymounkov and Mazieres Kademlia system?

只谈情不闲聊 提交于 2020-01-09 03:52:04
问题 I am struggling with the original paper trying to understand seemingly contradicting paragraphs. One example is where in 2.2 the authors declare that for bit space 160 there will be 160 k buckets, then later go on to say that in fact the buckets are a smaller number covering wider bit ranges and organized by prefix binary trees. In that 2.4 section they talk about unbalanced trees that lead to interpretations like the following, https://stackoverflow.com/a/32187456/442396 , where it is not

How to represent a kademlia routing table as data structure

南楼画角 提交于 2019-12-29 01:25:33
问题 The kademlia paper talks about the the organization of buckets, splitting, merging and finding the correct bucket to insert in abstract, concise and confusing terms. §2.2 talks about a fixed set of 160 buckets with each bucket covering a fixed subset of the keyspace. But later chapters involve additional splitting and buckets covering different parts of the keyspace. That don't fit well into a fixed list What is the correct way to organize buckets? Meta: Since the confusion is reflected in

Can somebody shed a light what this strange DHT response means?

本秂侑毒 提交于 2019-12-24 03:58:31
问题 Sometimes I receive this strange responses from other nodes. Transaction id match to my request transaction id as well as the remote IP so I tend to believe that node responded with this but it looks like sort of a mix of response and request d1:q9:find_node1:rd2:id20:.éV0özý.?tj­N.?.!2:ip4:DÄ.^7:nodes.v26:.ï?M.:iSµLW.Ðä¸úzDÄ.^æCe1:t2:..1:y1:re Worst of all is that it is malformed. Look at 7:nodes.v it means that I add nodes.v to the dictionary. It is supposed to be 5:nodes. So, I'm lost.

bittorrent DHT detailed specification

人走茶凉 提交于 2019-12-24 00:42:44
问题 In my new weekend project I decided to write an bittorrent client from scratch, no ready to use libraries at all. After two days looking for documentation I'm already about to give up :smile:. I know there are the BEPs, but they are far from enough to understand all the specification. After reading a lot more I think the tracker and peer protocols seems to be old and easy to understand/implement (yes, I know, to write a good code with balance, peer selection, optimizations, this is not easy

Highly unbalanced Kademlia routing table

末鹿安然 提交于 2019-12-17 18:36:17
问题 In the Kademlia paper, the last paragraph of section 2.4 states that in order to properly handle highly unbalanced trees... Kademlia nodes keep all valid contacts in a subtree of size at least k nodes, even if this requires splitting buckets in which the node's own ID does not reside. However, the previous section of the paper seem to state that if a k-bucket already has k elements, that any further additions in to that k-bucket require removing the stalest node (pinging it first to see if