一种简洁的流式推送文件分享法

　所谓简洁是相对于P2P多端同时协商同时获取数据, 同时还分享分发数据的复杂逻辑而言的. 这里要提的”流式推送”法, 是要简单的多的方法. 我会简单分析一下.
　玩过魔兽War3 RPG的人常常遇到要从主机那里获取自己没有的地图的情况, 自己名字前面会有一个0~99变化的数字. 那么不知你有没有注意观察和思考过,当一个房间4个人,只有主机有地图的情况下, 另外3个人是怎样拿到地图的? 经过我的观察和思考,他是这么工作的:

　主机是1P, 他先单传给2P, 另两个人干等. 2P收完后,1P传3P, 2P传4P. 这样理论上两轮就搞定了. 这种方式在最糟12个人的情况下, 也只要1->1->2->4->8 四轮可以搞定. 想想这种方式确实不算高明, 可是为什么人家那么牛的暴雪(Blizzard)游戏开发的牛人们会采用呢?简单分析原因:

1. War3的联机对战大部分还只是基于局域网 (Battle.net用的很少,我没有发言权), 局域网环境速度够快,额外消耗的等待时间很少,也能够容忍.况且等朋友的时间基本都比下图时间长.
2. 这种方式就是简单,作为游戏前同步地图的工作,完全没必要做的像专业P2P分享软件,满足需求,开发维护简单,使用稳定比盲目追求极致完美要更聪明的多.

 我对人家的理解还很粗浅,但是不管怎么说,我在这仅有的两条的启发下,打算在项目中引入类似这种的简洁推送法.
关于这个同样的需求在两三年前,我是毅然选择复杂的方法,越完美越好的. 时间的推移似乎使得我的要求渐渐变低了.

想起TX某项目组lead说我对自己的要求不高,我只能说:呵呵..

　我们的项目的其他模块负责将参与者互联在一起,我们的主角模块,我叫它”FlowShare”,不用考虑网络如何互相连接的问题.它的使命是从其他互连参与者那获取具有某个hash特征值的文件.速度很重要,速度也不是那么重要. 我的方法和War3分发地图法的最大区别可能就是他分发文件是一对一进行,接收者不会发出数据; 而我的设定是接收者也同时发出数据. 具体说就是每个人寻找一个上家获取数据, 自己也会成为别人的上家发送数据, 但是上家和下家在同一时刻都只分别保持一个.这样在下家下载的时候,它也可以同时分享给其他人(只有一个). 在向上家获取数据的时候,可能出现传输速度大于上家获取他的上家数据的速度, 这时, 可以重新协商筛选新上家. 如此在理论情况下,不论多少人, 在获取数据最慢的那个人下载好之前,其他所有人都已经下载完毕. 只需一遍.

　最后再重提一遍,这种方法怎么说都不可能是最好的方法,我的目标是取能力和代价的最佳折中来解决问题.