beta3 已发布
切换后重启一下程序
这一句翻译应该没错？允许任意文件打开，比如说打开exe，zip压缩包等
简体上叫操作中心，繁体不太清楚。。。等官方看看
这个还没修吗，退出软件如果有2天没打开，2天后打开的时候显示0积分 1.98及以前版本没这个现象
详细的测试结果来了
比特彗星BT任务区块内存缓存有效期是多久过期
种子正在有速度传输数据时，130秒无人访问内存，就过期
种子无速度时，未连接到任何peer用户，持续保持当前已有的内存缓存，直到下一位来访者在开始丢弃这些过期的内存
测试长效上传时，是会正常过期缓存的（但是不知道缓存是多久，，，因为分布太分散了不方便观察）
长效1.95反馈 1.96新增的，发现有个问题。。。今天仔细看了下，长效下载的客户端居然不是顺序的，是和BT一样乱序的一个一个区块块进行下载，假设BT任务是512KB区块，那么长效下载就是每次下载512KB区块
我之前以为是顺序的12345678910这样顺序。。。。
所以现在的版本导致了长效上传做种方内存需求量增长很大，差不多要1:1文件大小的内存作为缓存，不过做种方长效上传，长效命中率基本为99.9%了
做种方占用4G内存
下载方进度只有10%，因为乱序请求导致了申请大量的16MB内存
一个5GB 512KB区块的BT任务，仅BT任务传输情况，做种方只要90MB的内存。仅长效上传需要4GB
所以2.0版本我们要做的，，，就是把长效上传缓存在改进一下，和BT任务的区块同步起来？HTTP任务在保留16MB的算法。
例如BT任务种子是512KB区块，那一次就是区512KB内存，，，等等，好像长效上传方并不知道对方下载的BT任务？而且是能跨A B多个种子互通的。。。脑壳痛，有没有什么高材生大佬支个招
下图为BT任务时候，可以观察到长效是随机取区块的
（明明是基于HTTP协议，原来长效下载速度有时候也很慢，，，原因是和BT任务一样512KB一个块这样传输）
要不然和上面说的，，，出个选项控制下长效最大服务人数，或者缓存时间缩短到10秒过期，还是等个大佬看看怎么解决吧
还是说2.0的长效上传，仅服务2.0及后续版本，方便和下载方客户端对接整合一些代码来实现同步区块缓存大小啥的，比如下载方通知上传服务端我当前正在用多大的区块下载
作为长效下载的时候，可以支持兼容以前版本
太小的区块下载速度又太慢，例如512KB区块下载速度只有500-1000K极限了，不适合现代网速，16MB区块刚好对应百兆网速，比较符合现今高速下载需求。但是这个客户端随机请求下载有点头疼。
macOS版已发布，欢迎试用
下载连接点进去为什么页面显示Content not available in your region.
我用1.99版本下载，很多种子都是下载到百分之九十九多，然后就一直卡在那里了。
打开视频看，大部分都能正常播放。极少数提示解码错误。
bittorrent.separate_sources_for_failed_piece 的bug，改成否就可以了
在高级设置里我看到新增加的设置项network.enable_open_dns，中文解释是必要时使用。
我有2个疑问想问一下，谢谢
1.这个功能只在必要时才用吗？
2.这个必要时指的是什么时候？
感觉现在得版本CPU占用有点高啊，我5900X 不开彗星和开彗星 CPU温度能相差10度。。不知道能不能优化一下。以前我记得没有这么高占用
正式版也没有种子市场是咋回事？
仅当域名解析返回的IP地址是loopback地址的时候
问一下，关于种子市场的磁链交换机制
情况1：【我的共享：1000个】【他人共享：1千万个】
情况2：【我的共享：0个】【他人共享：1千万个】
情况1和情况2，交换出去的磁链，他人共享分别占几个呀
可以在流量图里面，切换CPU分类，观察是什么线程在占用cpu
windows11下需要使用hosts的时候使用，默认检测到dns存在劫持的时候，会使用opendns双重查询dns，来防止劫持，但是这个功能在国内没用的，然后微软Windows11还出了个dns api的bug，会导致手动指定hosts无效，所以提供了这个选项，禁用双重查询，可以确保在Windows11下使用hosts能起效果，微软后续更新应该会修复的，毕竟过度系统
HTTP任务下载，不受最大连接数控制
对不起大佬，是我没搞明白，我打开的是原来下载在桌面的bitcomet.exe，而不是替换过后的bitcomet.exe，抱歉
我看了下基本就是UDP传输线程占用得