XIU2

> /dev/null 💡 业余自学自给自足瞎折腾~

Results 297 comments of


                                            XIU2

mac 下载安装包之后，解压后应该如何运行CloudflareScanner，望告知

参考一下这个 [Issues](https://github.com/XIU2/CloudflareSpeedTest/issues/3#issuecomment-743767747)

希望能動態屏蔽比特彗星 BitComet

BC 是在对 BT 整体上传后如果还有上行网络空余（即没有跑满上传或上传限速上限），则会 **用剩下的网络进行长效种子上传。** 而且长效种子功能是可手动关闭的，同时只有设备拥有 **公网IP** 的情况下，才能实现长效种子上传，这在中国很稀少。。。准确的说，吸血的定义是只下载不上传(或非常少)，迅雷才是当之无愧的吸血~

@Zerorigin 看到你这个回复，我就知道 **你根本没有对比特彗星的长效种子机制详细的了解分析过。** **** 我在接触比特彗星后，见到一些人说长效种子吸血，为此我特地观察了一段时间研究了下。首先长效种子是可以关闭的，但因为只有比特彗星支持，所以被一些 **没了解过就下定论的人认为比特彗星和迅雷一样，都只上传给自己的用户** ，然而实际上是： - 当你平常做种时，比特彗星会优先对BT任务整体上传，如果还有空余上传速度（例如没多少用户需要你上传，上传速度跑不上去，或者你对任务限速），才会开始长效种子上传。 > 需要打开长效种子的「自动控制上传限速」功能，这样比特彗星才会根据上传速度的空余自动调整长效种子上传限速数值。 - 当你的任务满足做种条件停止后（例如分享率到达 300% 停止做种），比特彗星依然会持续做种（长效种子），因为长效种子只有比特彗星支持，所以也只提供给比特彗星用户。 > 用户主动停止做种，或者任务满足做种条件停止，都属于用户主动放弃继续对 BT 整体上传。 ### 总结：...

希望能動態屏蔽比特彗星 BitComet

- **第一点：** 【谁也無法知道？？？】既然你不知道，那就代表没证据，那不就是猜测的么？ - **第二点：** 连接数的确会被占用，但是连接数上限足够高（例如我设置的 9999），不可能跑满上限（但会因为电脑性能出现瓶颈），可能我的上传速度不够快，观察不到你猜测的情况。我的上传速度大部分情况下都能跑满，而这时候长效种子只占用了 0-100KB/s 上传速度，剩下的都是 BT 整体上传，你是否真实检测过比特彗星在限速长效种子后是否正确释放长效种子连接数？还是说依靠猜测？ **你说的连接数我不否定，但是你说的【很明顯可以看出 BC 客戶端具有很强的吸血能力】我不认同。** 你在1楼发的一段话，可不像是 **【“恰恰相反，你说的這些我都了解过。”】** **** **例如：【分享率到達或超過預設值后，並不分享給其它客戶端，反而擠占了本該用於分享給 DHT 網絡上其它 BT 客戶端的帶寬，違背了 BT 的公平性原則】** 分享率达到用户设置的停止条件时，代表用户主动放弃了对 BT 整体的做种上传，和长效种子本身无关，如果用户打开了长效种子，那么就进行长效种子做种，如果关闭了，则不会进行任何做种上传行为。**这是用户主导的，而不是软件强制的。** **** **例如：【這點上和迅雷(Xunlei)類似，從...

通过http获得可用的机场代码测速ip后，能否二次筛选一下？

> 因为测出来的ip基本不能用，甚至可以算是bug？得出的结果后，还要人工去用cmd傻乎乎的去curl确认ip可用情况太不科学了。 CloudflareST 的 HTTPing 测试，和 curl 测试原理是一样的，理论上测试结果是通的就能用，如果不能用就是其他因素影响了（例如墙/运营商的干扰，像我这边平时都不会用 HTTPing 测试 Cloudflare IPv4，因为越测越少，每次测试都有大批 IP 被干扰阻断。。。测的时候是通的，但等我手动去 TCPing 就是超时了）。你这种需求，建议用脚本去实现，每次测速后，再次对结果进行测速筛选。因为 Cloudflare CDN IPv4 被我这边联通干扰阻断了，因此我这边是完全用不上 `-cfcolo` 功能（IPv6 的话数量太多，大海捞针测速太慢，也懒得用），这也是我当初为什么一直没有添加该功能的原因，也是后来有人写好提 PR 了我才加上了，因此我也没啥动力去对 `-cfcolo` 功能更新完善。。。 >...

http模式下，检测到可用ip超过10就跳过后续未完成的检测延迟，直接进入下载测速阶段节省时间

这个的话，我不确定是否为**大众需求**（就是不少人会需要的功能）。一般什么情况下会产生该需求？请举几个例子。毕竟一般来说，大家都是希望延迟测速所有 IP 后，排序**得到延迟最低的 IP**，再去下载测速或直接使用。而如果只需要 10 个可用的话，那么代表你**不在乎可用 IP 的延迟/丢包**，或者说你**预先知道了这些可用 IP 的延迟/丢包情况都差不多**，因此也不挑。如果没什么人会用到的话，我可能会懒得去添加。。。对该功能感兴趣的其他人也可以在下面回复或给本条回复点表情，我看看有没有其他人需要该功能的。

http模式下，检测到可用ip超过10就跳过后续未完成的检测延迟，直接进入下载测速阶段节省时间

正好有空，就顺便研究下，不过试了下发现似乎不好完美实现。因为理想情况下应该为：**延迟测速可用 IP 数量等于 10 时，立即终止所有延迟测速线程，停止创建新线程，再继续后续步骤。** 但我发现停止创建新线程可以实现，而立即终止所有延迟测速线程有点麻烦，主要问题在于这些线程处理的都是网络链接，而非本地计算，因此并不是说终止就立即终止，实际上终止这些线程也是需要时间的，而我半吊子的 Golang 也不好解决该问题，于是干脆停止创建新线程并丢弃所有后续线程的延迟测速结果。这是我编译出来的测试版（因为是测试，所以代码写死了 10 个）：[CloudflareST_beta.zip](https://github.com/XIU2/CloudflareSpeedTest/files/11581248/CloudflareST_beta.zip) 使用时，看似延迟测速结果只有 10 个，但实际上还是测速了 200 个（取决于 -n 延迟测速线程参数，默认为 200），只不过当可用 IP 数量大于等于 10 个时，后续的 IP 延迟测速结果都被丢弃了。...