资料上说bitfield是分块的位表示结构,即表示每个用户正在下载的文件中那个块是下载了的.
假如说有1000个正在下载10个1G的文件,一个块的大小为1M,这样1G就分成1024个块.
那么Tracker服务器上保存的btfield结构为:1000人*1000块*10个文件/8(1个字节8位)=1250000字节
BTComet分块甚至可以是32K,那么这个bitfield结构就更大了,被分成32768个块,这样就要40960000字节的空间了,是不是这样理解呢?

解决方案 »

  1.   

    记录的信息应该还包括每个用户的IP地址及文件名,这些内容按指定长度写入文件中,用内存映射读的话,几十到几百M的文件应该挺快的。服务器只要告诉每个用户把他硬盘中已经下完了的哪些块发到哪个用户的IP去,自己剩下的带宽再用来优先提供大家都没有下到的那些块就行了,负担不小,但也没大家想象那么大。
      

  2.   

    我是在想这个数所是保存在Tracker服务器上还是每个用户各一份呢?
      

  3.   

    如查向服务器发个请求,服务器广播下的哪个客户端有所需数据,找到后负责链接.当然bitfield可以以缓冲的形式存在.
      

  4.   

    我是在想这个数所是保存在Tracker服务器上还是每个用户各一份呢?
    -----------------------------------------------------------------------------
    我想应该是服务器上保管所有用户和文件下载实时情况的全部信息,就象一个数据库的服务器端;用户手中也数据库的部分数据,里面应该只有自己正在下载的文件的详细情况和目前其他正在下载该文件的用户的IP等信息,就象数据库的一小部分。
      

  5.   

    至于楼上XueBoy163(菜刀之恋)朋友说的“bitfield可以以缓冲的形式存在”这种看法,我觉得不大可能,否则我若下了几个小时之后电脑非法关机,那这几个小时的下载信息没有在本地硬盘中记录,不就等于白下了?!也许你会说,不是还有服务器端的数据记录嘛?!但我下次重新下的时候很可能IP就变了,服务器端怎么知道每个用户的“前世今生”是谁?以上纯为个人猜测,不一定正确,欢迎大家交流!
      

  6.   

    不是这回事,bitfield是指哪个客户端有哪些数据,并不是指下载的数据.
      

  7.   

    那这几个小时的下载信息没有在本地硬盘中记录,不就等于白下了?!
    ----------------------------------------------------------------------------------
    我上面所说的这个”下载信息“也是指XueBoy163(菜刀之恋)朋友说的这些内容,而非“下载数据”,里面记录的是用户某个文件已下完了哪些块,以及还有哪些块还没下。
      

  8.   

    服务器记录的是1000*1000*10/8
    客户端只记录Tracker返回的peers的相关信息,BitComet一般会返回300个。
    Tracker记录客户端的块信息的开销不算很大。不过BitTorrent系统的瓶颈本来就在Tracker服务器。
      

  9.   

    至于服务器是怎么样记录实时情况的。我也在关注关注。。prettywolf(多情自古空余恨,此恨绵绵无绝期) (
    应该是有缓冲,不过是每2分钟服务器和客户端更新一次.
    。是不是更新了就保存?