这个已经实现了，长效种子就是，使用的CDN传输协议技术，基于HTTP进行传输，并非是BT协议
这个技术太老了，
你说的那个分散式碎片存储并不太现实，并不能有效解决下载问题，很容易出现，进度下载比如说5%，就死种，导致无法正常下载完成100%，而且还要设计用服务器来调度控制，需要分散到哪些机器上，数据库记录等等，毕竟比特彗星是国外软件，这样干不太现实。。欧盟对隐私协议看的很重
分散式碎片存储只储存100%已下载成功的完整文件，不过需要一个大服务器先做了完整缓存再发送到客户机，说实话，没有足够资金和利润去实现确实有点难。
分散式碎片存储这绝对是速度最快最安全的解决方案
对的，，例如上方说到的，文件只有5%的区块进度，剩下的95%需要从服务器发送到客户机，然后客户机才传给下载用户，才能进行正常的下载。所以下载原理来说，不如现在的长效种子实现方案有优势，现在只要有长效种子，就一定能100%下载完成，因为他是完整的存储文件进行传输，并且也不需要服务器去存储这些资源文件，，毕竟人家软件也没盈利，万一有哪天盈利化了，，说不定会改动这样
长效种子需要外网ip端口，分散式碎片存储不需要外网ip端口，任何时候高速下载。可以看看迅雷赚钱宝或者玩客云的方法。
玩客云也需要端口的，你没发现公网IP端口上传玩客云快很多吗，必须要有一方是外网IP，例如玩客云的用户没有外网IP，他只能上传给拥有外网IP的用户。迅雷老良心了，服务器砸了多少钱进去的说
长效种子现在是，必须要拥有长效种子的一方有外网IP，下载方有没有都无所谓。
不过这个要改动的话，其实是好解决的，主要还是成本问题，会导致大量的查询请求到服务器中。看看官方开发者要不要做吧，毕竟要与服务器查询数据库进行通讯，这样长效种子会查找当前的下载用户，主动发起请求给下载用户进行上传就可以实现你说的外网IP的问题了。
老大，cdn那些太遥远，看你能不能弄一下，增加一个停止所有低于0kb/s的下载任务，将0kb/s的下载任务移到下载列表最后面，启动多个候补下载任务去顶上已停止的多个下载任务的功能。目前5分钟只停止一个任务再启动一个新下载任务，这个功能太弱了。
我不是官方人员，，，普通比特彗星使用用户而已，这个你要等官方人员上线后看看你的想法了，也就是楼主
经过测试 终于排查出一个mac上严重影响使用的bug 就是选项里第一栏网络连接中一旦限制了上传速度 cpu占用率马上暴涨 即刻生效
反而不限速跑满上传 cpu占用只有50%左右 其次我看有另一个用户在二月份时发的贴 他开启了时段限速也同样遇到cpu和风扇爆转问题 另外还有一个小问题就是状态栏里改限速是无法生效的
感谢反馈。Mac版网络底层代码和Win32不太一样，还需要优化。最新发布的v1.74 Mac版已降低了不限速时的CPU占用率，欢迎试用。
是指界面选中了上传限速，但实际没有生效吗？
积分只有20分的问题
早上8点的时候客户端不能退，那时候上传数据进行更新积分，有时候会有网络问题也会导致更新失败，所以只统计20分，，，或者全球这么多用户，大家都同时提交，服务器卡了，然后排队，排队失败就不计算分了，所以我觉得让官方每上传100M立即提交增加10积分更为科学
3個讚
支持小樱
积分天天都是20分，上传都不给我积分，，，
还有，每天都是，每到晚上6点后，帐号就无法登录
1個讚
是的，界面上传的bug新的测试版已经解决了。我看你回复的是降低不限速时的cpu占用率，但是我反馈的是限速时的占用率 
经过测试，限速后cpu问题依旧，希望能继续完善，谢谢。我用的是20款MacBook Pro 英特尔版本 系统为Big Sur最新版
感谢反馈。限速时的占用率问题已记录下来，后续版本继续改进
末來版本能否優化一下正在下載時右鍵停用某些檔案時的處理速度(右鍵檔案列表的已停用)…
當數量很大的時候會卡住超級久…都是CPU使用率佔高
安卓版本现在内存最大值是多少？我12G的手机能不能设置6G缓存给他运行做种