Web——P2P应用

纯P2P架构没有服务器，任意端系统之间直接通信，节点阶段性接入internet，节点可能更换IP地址。其缺点是比较复杂。

具体应用：文件分发  C/S vs. P2P

客户机/服务器：

服务器串行发送N个副本：NF/us

客户机i需要F/di时间下载

所需时间随用户数量N线性增长，当N特别大的时候，难以进行。

P2P

服务器需要发送一个副本F/us

客户机i需要F/di时间下载，所有客户机都需要下载，共NF比特

最快的可能上传速率：us+Σui

 

文件分发：BitTorrent

文件划分为256KB的chunk；

节点加入torrent：

刚加入时没有chunk，但是会逐渐积累；

向tracker注册以获得节点清单，与某些节点建立连接；

下载的同时，节点需要向其他节点上传chunk；

节点可能加入或离开，一旦节点获得完整的文件，它可能（自私地）离开或（无私地）留下。

节点获取chunk：

给定任一时刻，不同的节点持有文件的不同chunk集合；

节点定期查询每个邻居所持有的chunk列表；

节点发送请求，请求获取缺失的chunk。

（稀缺优先：需要的chunk只有很少节点可以提供时，先请求这样的chunk。）

发送chunk（原则：“一报还一报”）：

节点向4个邻居发送chunk（正在向该节点发送chunk的4个最快的节点——对其贡献最多的4个节点，每10秒重新评估top 4）。

每30s随机选择一个其他节点发送chunk（optimistically unchoke)——新选择的节点可能加入top 4中。

——上传速率越高，能够找到更好的合作伙伴，从而更快获取文件。

 

P2P应用：索引技术

P2P系统的索引：信息到节点位置（IP地址+端口号）的映射。

文件共享（电驴）

1. 利用索引动态跟踪节点所共享的文件的位置
2. 节点需要告诉索引它拥有哪些文件
3. 节点搜索索引，从而获知能够得到哪些文件

即时消息（QQ）

1. 索引负责将用户名映射到位置
2. 当用户开启IM应用时，需要通知索引它的位置
3. 节点检索索引，确定用户的IP地址

集中式索引

Napster最早采用这种设计。

节点加入时，向中央服务器报告IP地址和内容。

缺点：虽然内容和文件传输是分布式的，但是内容定位是高度集中式的。

1. 单点失效问题，如果服务器挂掉，所有用户将无法使用；
2. 性能瓶颈，受中央服务器的性能限制；
3. 版权问题。

洪泛式查询:Query flooding

完全分布式架构。

每个节点对它共享的文件进行索引，且只对它共享的文件进行索引。

覆盖网络：

1. 节点X与Y之间如果有TCP连接，那么构成一个边；
2. 所有的活动节点和边构成覆盖网络（逻辑网络）；
3. 边：虚拟链路；
4. 节点一般邻居数少于10个；

查询消息通过已有的TCP连接发送。

节点转发查询消息。

如果查询命中，利用反向路径发回查询节点。

洪泛式查询会大量消耗网络带宽，导致网络堵塞。

层次式覆盖网络

介于集中式索引和洪泛式查询之间的方法。

每个节点要么是一个超级节点，要么被分配一个超级节点（普通节点）。

普通节点和超级节点间维持TCP连接，采用集中式索引；某些超级节点对之间维持TCP连接，超级节点之间采用洪泛式查询。

超级节点负责跟踪子节点的内容，为子节点提供索引。

e.g.Skype采用层次式覆盖网络架构

本质上是P2P的：用户/节点对之间直接通信；采用私有应用层协议层次式覆盖网络架构；索引负责维护用户名与IP地址间的映射，索引分布在超级节点上。