6.2-P2P系统第二部分.pptVIP

非结构化P2P系统中定位内容的问题 P2P系统工作过程 内容定位 Peer节点之间的协作：请求和服务内容 集中目录：由于中心目录服务器不可行 性能 可靠性 其它问题：版权侵犯定位 分布式 泛洪式查询，查询的速度取决于副本的数量 需要查询越快，需要副本的数量越多 有没有在不增加副本数量的情况下，可以大幅度提高查询速率的技术 * 3. 结构化P2P: DHT方法 DHT 服务和问题 CARP Consistent Hashing Chord CAN Pastry/Tapestry * 挑战: 在不增加副本情况下提高定位内容的速度 最简单的策略：泛洪、扩展环形检索 如果N中K个节点有这个拷贝，期望的搜索代价最小：N/K, i.e., O(N)（本质上是遍历） 如果需要检索代价较小的话，需要很多的缓存拷贝数量 I’m looking for NGC’02 Tutorial Notes Here you go! Here you go! * 直接检索 思路: 赋予一些特定的节点去存储特定的内容（或者存储指向这些内容的指针，像信息亭） 当一个节点需要那个内容时，去相应存储这些内容或者知道这些内容的节点那里去获取内容 挑战： 分布式：需要在覆盖网络中的那些节点中分布这些存储或者指针的任务 自适应：节点加入和离开P2P覆盖网络 对于新加入的节点，将任务分配给它们 对于离开的节点，将它们原来承担的责任分布给还存在的那些节点 * DHT步骤1: The Hash 引入一个哈希函数将一个被检索的对象映射到唯一的标示: e.g., h(“NGC’02 Tutorial Notes”) → 8045 在P2P网络中的所有节点中，分配hash函数值：知道这些对象的存储位置或者干脆存储这些对象（2种选择）； 每个节点必须要“知道（存储或者指针）”它管辖（分配给它的）对象的一个拷贝 0-999 9500-9999 1000-1999 1500-4999 9000-9500 4500-6999 8000-8999 7000-8500 8045 * “Knowing about objects” 2种选择 节点缓存那些属于它管辖范围的对象 基于指针的：节点缓存指向对象的指针 0-999 9500-9999 1000-1999 1500-4999 9000-9500 4500-6999 8000-8999 7000-8500 * DHT 步骤2: 路由 对于每个对象，到达 管辖这些对象的节点 必须可以通过一个较短的路径到达 或者被查询节点 (assumed can be chosen arbitrarily) 或者被那些拥有这些对象拷贝的节点（当采用基于指针的方法） 不同的方法(CAN,Chord,Pastry,Tapestry)主要区别在于路由的方法 任何一个 “好的”随机哈希函数都能够满足需要 * DHT 路由: 其他的挑战 可扩展性：每一个节点的邻居节点数量都应该随着覆盖网络节点的增加，保持可扩展性(e.g., 不应该是O(N)) DHT 方案应该是完全分布式（没有集中式的节点，可能成为吞吐的瓶颈以及成为单点故障点） DHT方案应该能够优雅地处理覆盖网络节点的加入和退出 加点加入时和退出时，需要在已经存在的节点中间重新分布各节点管辖范围 需要重新组织邻居集合 需要能够将新节点连接到已经存在的DHT基础设施的自举方案 * DHT API 每个数据项（例如：文件或者包含指针的元数据）都在一个相同ID空间有一个key 在每个节点中，DHT软件提供API： 应用向API输入key k API能够返回负责k节点的IP地址 间接方式 DHT 给出key所在的位置 再通过Peer之间的协作传输文件或者计算等 API在下层的DHT覆盖网络和分布式算法中被实现 * DHT API application DHT substrate API application DHT substrate API application DHT substrate API application DHT substrate API overlay network key responsible node 每个数据项(e.g., 文件或者指向文件拷贝的 元数据) 都有一个key * DHT 分层架构 TCP/IP DHT Network storage Event notification Internet P2P substrate (自组织覆盖网络) P2P 应用层层 ? * 3. Structured P2P: DHT Approaches DHT service and issues CARP Consistent Hashing Chor