项目主页：http://azureus.sourceforge.net/
原理：节点选择所需要的信息都已经被内容分发网络(CDN)给收集好了，CDN使用动态DNS将用户请求引导到低延时的备份服务器处。
作者认为若两个用户被定向到一组相似的备份服务器，也就说明它们离此服务器很近，进而说明两者之间也很近。这种基于CDN的信息能减少跨ISP的流量。
和上一篇的思路不同，不需要新的网络设施，不依赖ISP和用户之间的合作，不使用路径监控和路径探测。节点只需要能够对于CDN名字进行本地DNS查询就可以了。
若节点Pa被重定向到服务器r1的概率为75%，定向到r2的概率是25,则对应的向量是Fa = <r1->0.75,r2->0.25>。每个节点都可以使用一个向量来表示它重定向的概率，进而通过两个向量的余弦相似度计算就可以得知两个节点是否是在同一个自治区域内。
使用一个基于java的DNS客户端对于CDN名称进行周期性的DNS查询，这是为了维护比率映射表。为了计算一个节点和其他节点的余弦相似度，必须比较两者的比率映射表。这可以通过多种方式获得：直接在节点间交换比率映射表信息。从分布式存储处，从Tracker服务器处。Ono插件目前支持前两种，当两个节点开始连接握手时，就交换比率映射表。而对于分布式存储的方案，实现了一个基于DHT的方法来存储和检索比率表。
当Ono认为另一个节点有着类似的定向行为后，它就会把流量都偏向到那个节点处。为了进行偏向性的节点选择，Ono必须位每个用于DNS查询的CDN名称维护一个比率映射表。Ono对于每个CDN名称进行DNS查询，从而判断重定向行为，将这个信息编码位比率映射表。因为CDN倾向于将服务器集群成组，并赋予其相同的C类子网，因此我们使用包含24位地址的备份服务器集群，而不使用其全部的IP地址。
当对于一个CDN名称进行完DNS查询后，就根据重定向频率结果调整相应的比率映射表。对于映射表中已经存在的比率的生存期使用指数递减的方式。在过去24小时内一个备份服务器没有回应的话，则会被从比率映射表中删除。对于DNS查询返回的备份服务器集群的比率会增加，确保所有比率总和为1.
随着用户网络位置的改变，重定向行为也会随之变化。为了解决这个问题，使用如下方法： 当一个用户没有重定向信息时，它会在两分钟内，每隔30秒对每个CDN名称进行DNS查询至多1次，从而建立起它的偏好比率映射表。在这个阶段以后，若对于当前CDN名称的重定向信息与前一次查询没有变化，则DNS查询的时间间隔增加1分钟。若在时间间隔内，重定向行为改变了，则时间间隔减半（30秒）。在BT的会话结束时，Ono 会在硬盘上cache比率映射表。若比率映射表够新的话（小于24小时），则避免了前面的启动阶段。
若一个节点和它相关联的备份服务器之间路径的延时很大，则CDN映射信息对于邻接点的选择并无多大作用。为了动态确定有用的CDN名称集合，Ono对于DNS查询返回的备份服务器使用了ICMP ping，RTT值越小，则相关联的名称在偏好节点选择过程中的权值越高。若RTT高于平均水平，则将此映射从比率映射表中排除出去。
本文转自Phinecos(洞庭散人)博客园博客，原文链接：http://www.cnblogs.com/phinecos/archive/2008/11/21/1338555.html，如需转载请自行联系原作者
