>可能有数百万的种子数量
>洪流大小从100Mb到100Gb不等
>世界各地一组稳定的集群,能够充当播种者,每个集群都拥有大量的种子(平均为60％)
>相对较少的同时用户(少于100个)希望平均下载几TB的数据.
我预计活动种子的数量与可用总量相比较小,但服务质量很重要,因此每个种子必须有几个播种机或一些推出新播种机的机制.
我的问题是,bittorrent客户可以处理播种大量的种子,其中大部分都是空闲的吗？我是否需要在群集中的种子上划分种子,或者每个节点是否可以播种它可以访问的所有种子？哪个客户会做得最好？是否有任何工具来管理播种群？
我假设跟踪器可以扩展到这个级别.
解决方法
>每个torrent(通常)需要定期向跟踪器宣布,这可能最终会占用大量带宽.
> bittorrent客户端本身需要以与大量种子一起扩展的方式编写
至于跟踪器流量,让我们假设您有100万个种子,典型的重新宣布间隔是30分钟,但是一些跟踪器将其设置为1小时.让我们保守一点,假设你的跟踪器使用1小时的通知间隔.你必须每小时发出100万个GET请求,假设每个请求是400字节向上和100字节向下(假设大多数响应不包含任何对等体),那就是大约111 kB / s向上和28 kB / s不断下降.这并不是那么糟糕,但请记住,TCP需要额外的往返来建立连接,因此另外40个字节向下,40个字节向上.
这可以通过仅使用UDP trackers来缓解.然后您只需要一条连接消息,并且您可以为每个通告重用连接ID.然后每个通告消息将是100个字节,并且返回的消息也将更紧凑,假设60个字节.这样可以让你获得28 kB / s和16kB / s的速度,只是为了防止洪流宣布.为此,您需要一个具有良好udp跟踪器支持的客户端(例如,缓存连接ID的客户端).
还不错,假设与种子发送的实际数据相比,这是微不足道的.
但是,您不一定需要在不同的数据中心划分种子,也可以使用HTTP服务器为种子播种.所有主要的bittorrent客户端都支持http播种,你不必担心向跟踪器发布消息(URL被刻录到.torrent本身).
对于一个可以很好地适应种子的客户,我不确定,我还没有做过任何测量.只生成一百万个随机种子并尝试加载它应该是相当简单的.
我在libtorrent rasterbar做了一些优化工作,以使其在许多种子中很好地扩展,但我没有尝试过数百万.
