提个建议，关于临时汇报tracker，获取种子用户量信息，进而帮助用户判断种子市场的种子是否还存活。
大概流程（就大概比划一下，描述不一定很到位）：用户在种子市场，选中种子（单选或多选），右键点击种子出现菜单，菜单里有个选项【种子测试】，点击种子测试后，就会汇报种子获取当前保种人数信息，在【热门】这一列（或新设置单独一列），就会出现保种人数的数据。
至于汇报到哪个tracker，内置固定的tracker，或使用用户自己的tracker列表里的tracker，或单独设置一个tracker栏让用户自己填，感觉都挺好。
如果几个tracker服务器回报的保种人数不一样，那可以取最大值。
adhome 确实好用 我现在用的也是这个
最好是设置为路由器的上游dns
唯一可惜的是不能设置为通过代理进行查询 不过在二层进行分流还是可以的
一般情况下不用DOH用TCP也能防污染
问题反馈
为任务手动添加标签后 选中的任务标签会自动跳到最后一个
如果要做可以学utorrent发送scrape请求，仅查询当前种子的人数，没有开始停止等操作，不会把自己的ip公布到tracker列表中，也不会获得完整的peer列表占用服务器宽带，只获取种子人数
http://www.bittorrent.org/beps/bep_0048.html
[30/May/2019:19:06:10 +0000] "GET https://域名/scrape.php?passkey=xxxxxxxxxxxxxxxxxxx&info_hash=%aa%29U%e0%eb%3e%ddW%04%ea%8f%c0%85%1f%aa%91.bx%ae HTTP/1.1" 200 106 "-" "uTorrent/355(111914906)(44954)"[Kt51] 16b0a22a102-7fe23aac2600
[30/May/2019:19:06:11 +0000] "GET https://域名/announce.php?passkey=xxxxxxxxxxxxxxxxxxx&info_hash=%aa%29U%e0%eb%3e%ddW%04%ea%8f%c0%85%1f%aa%91.bx%ae&peer_id=-UT355S-%9a%af%8a%5c%f3%10%1dz%073%9f%9b&port=22222&uploaded=0&downloaded=0&left=45292905933&corrupt=0&key=86386A7E&event=started&numwant=200&compact=1&no_peer_id=1 HTTP/1.1" 200 1850 "-" "uTorrent/355(111914906)(44954)"[Kt197] 16b0a22a4d7-7fe23aac2600
多选时候可以根据bep48列举出来的，同时附带多个info_hash字段，此时仅产生一次查询请求
大種子空間怎樣操作才不會導致硬盤100%寫入?
預分配開不開都一樣…打開種子直接100%…除非等他搞完
有詳解嗎?
安装磁盘提速服务，托盘处会提示安装，或者在高级设置中安装
之前说的根据ip库屏蔽某些国家2位代码看来还没搞出来，要不然方便增加一个ip过滤文件吗？其它bt软件都具备这种功能
需要支持匹配和list相同成功拉黑，或者非模式匹配（不在ip列表中就拉黑，也就是ip白名单模式）
例如transmission，utorrent等都具备ip过滤功能
https://bbs.itzmx.com/thread-20519-1-1.html
数据来自IPIP数据库免费项目地址：GitHub - 17mon/china_ip_list
我自己转换的一个格式，第一行代表更新时间或者更新hash信息等用于变动列表验证，第二行是ip地址，第三行为空
http://github.itzmx.com/1265578519/kangle/master/ipip/china_ip_list.txt
这图一看就能明白吧，是不是很好理解，ip库可以和tracker list那样点击后更新，图上是其他软件放内存中，比特彗星可以把ip库文件和db文件一样，放本地（在简单来说，和比特彗星官网屏蔽中国地区下载软件一样，要客户端能够支持这种效果！）
检测到匹配ip成功，在connect发起之前，就自动进入用户ban列表10天拉黑，并且这一次产生的connect请求不会发起成功。
要做的话，得注意http协议规范中的414状态码限制，request body size limit，一次产生的url长度不得超过255，post header请求数据不得大于8MB
// https://www.ietf.org/rfc/rfc2616.txt
3.2.1 General Syntax
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
不过现代浏览器的url支持到2048长度了，包括nginx iis服务器一般也不会限制太死的长度（nginx视乎是8192）
info_hash v1的话，包含域名本身长度，255也只能容纳3-4个hash，感觉视乎也没必要浪费时间做组合请求了，每个info_hash查询请求都单独发就算了。
直接把32bit的放一个文件夹里, 只留64bit甚至改名删掉_x64
啥流量？PCDN吗？
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版本下载，很多种子都是下载到百分之九十九多，然后就一直卡在那里了。
打开视频看，大部分都能正常播放。极少数提示解码错误。
