Beta5 应该已经修复了，试试看
Beta5 在发起uTP连接时，会优先使用之前连入过的远程端口，应该可以A反向连接到B了，试试看
早期的rss种子条目没有记录rss源标题，可以用此选项筛选出来
Beta5 实测没用，停止任务后还是卡住，可以看到一直在反复重试。。
甚至还能看到这种状态。。
测试是可以A反向回连B了，但是这样会出现A看到远程端口和监听端口一致，不太方便判断对方B是公网ip还是nat1打洞用户了。
而且测试发现出现了一个问题，像我之前说的，C果然没办法从A使用PEX获取到B的NAT1端口信息了，破坏了原有的ABC打洞逻辑，所以还是我之前说的那种收到远程连入UTP请求后，直接在A对自身客户端模拟PEX（不需要经过网络连接他人，代码实现PEX方式加入A自身的peer中）出来一个新的peer ip加端口方法更好，你这个覆盖端口的方案不行！
所以beta5的代码可以废弃回滚重新写了。。
感谢反馈。网络丢包造成的各种问题比较难以全面测试。我又做了改进，下一版试试吧。
beta5只修改了回连时选择的端口，从监听端口改为之前连入过的远程端口了。两个端口都有保存，没有做覆盖的操作。不过beta5显示有误，下一版已修复。打洞流程没有变化，应该也不会受到影响，我用ikuai虚拟机多测试测试。
原来是显示问题吗？所以为了避免脑子视觉混淆，我感觉还是我说的那样，新生成一个PEX比较好吧。。。
beta6 发布了，试试看吧。
Beta6 测试ws tracker任务停止后，可以正常停止了，还剩下一个没停止掉，，在持续运行，手动开始任务在停止一下就停止掉了，应该不碍事了
可能是停止的时候触发了什么导致没停掉某一个
保持现状就好了，这块不用改动了，，或者想的话，，也稍微改一下修复，试了几次观察到如果停止还运行某一个任务的ws tracker日志是这样的
2022-09-20 01:24:28 Tracker connection error: 1000 normal close
正常停止，不在继续运行的ws tracker日志是这样的
可能和ws tracker服务器返回了一个invalid info_hash有关系。。我建议是做到完美，还是找一下ws tracker这个提示停止不掉的问题吧。
beta6测试成功了，，在支持AB打洞的同时，正常恢复了ABC打洞。
还有个问题，，，通过UTP打洞，在A返回到B的远程端口PEX，比建立握手后立马返回的IPV6等PEX信息要慢9-10秒左右，能优化下返回速度？可以做到瞬间PEX返回远程端口吗，延迟10秒不太好吧。
还有就是，，，让我试试能不能在PT种子里面实现打洞
好了，beta6私有种子测试AB打洞成功，ABC不行，C没办法从A拿到B的PEX信息，这个能不能做一下呀，就和我一开始说的那样，，，用传递IPV6 PEX的方式传递下这个信息。只传递自身的IP地址信息，我认为是符合私有种子协议规范的，因为不是交互第三方peer列表。毕竟你看传递自身IPV6地址信息给他人都可以做，为什么这个UTP打洞不同时做一个呢
最后就是，，速度优化问题了。。美国服务器到国内360ms延迟情况。。建立握手后一直0KB/s
德国280ms有7KB/s，这个速度太离谱了，实在不适合如今千兆入户。。。又不是十年前ADSL 4Mbps宽带接入只有56KB/s的上传速度
随后挑出来网络调试工具，，，在美国服务器上发起utp回国内自家电脑，发送200Mbps，，，依旧也是跑满200Mbps啊，速度慢问题麻烦修修。。。
还有就是，，，比特彗星正常下载的时候也会产生大量的发送utp包，这正常吗？基本都是左右对等的，，其他BT软件没注意去看，不知道是不是也是这样
针对HTTP下载，能不能加个顺序下载的选项？例如在选项里加个HTTP顺序下载
很明显可以看到区块是分散的，不是BT那样从头到尾的顺序
https://speed.hetzner.de/10GB.bin
其它下载软件例如aria2使用–stream-piece-selector=inorder参数好像就可以顺序下载HTTP
大概就是，，，把rang发起的请求地址尽量放在前面一点，例如每个线程间隔32MB（对应设置的HTTP缓存大小）的位置试试？
线程1下载0-32MB，线程2下载32-64MB，以此类推实现顺序下载。如果使用200线程，缓存大小为32MB时候，如果文件大小低于32*200=6.4G时候就不知道要怎么考虑了。文件过小的时候可以用原始的分散下载？
这样做顺序下载就是会增加硬盘写入次数，因为要写入更多次了。
beta7 已修正
beta7 已优化
beta7 新增了此功能，默认开启，可以试试看
下一版本看看怎么改
有可能是其它BT软件发送过来的，彗星按照协议回复一下。如果在选项里把uTP禁用，应该就不会有回复了
每条HTTP连接都是顺序下载的，要么只开1条连接，就是纯顺序下载了
我是1.92的1.94下载不了啊为什么啊
显示什么呢
实测不行。。。依旧偶尔有极少数任务有这种情况。
这个会占用每秒UDP发起数量，，导致触发高级设置阈值引起下载变慢，有什么好办法优化一下？
说不定大量种子做种下载，UDP缓冲区队列过多因为内存占用高导致内存不足崩溃的也是这个引起的。
额，我是指，200个连接线程里面，优先下载文件前10%，然后20%，30%这样下载的意思。。。可能没说清楚。
你那测试正常吗？我这直接不返回远程端口的pex了。。哦，，等了70秒后返回了，，怎么比之前10秒还要离谱？？
要的是能做到和IPV6 PEX那样瞬间。。收到连入后瞬间响应过去。这比上一个版本响应PEX还慢了
实测没用，不知道是不是因为因为上面那个优化了，导致长时间不返回远程端口的问题。。。我等了5分钟也还没收到PEX，或者这个功能没成功。。
看来今天没新版。。
beta8 已加入。之前的两个问题应该也改好了。
停止ws tracker，测试效果非常不错，已经完美了！可以成功停止掉
还行，，目前测试是在7秒返回，还没pex返回ipv6来的快。。。应该还能进一步优化PEX响应速度。
看了下大概是在下载大小和上传大小发生变化的时候才返回，如果是0KB的话，，则会等待几秒速度起来了才返回
如下图，A方已经提前好几秒收到了远程端口，应该拿到远程端口的时候就可以PEX返回了
私有种子下依旧不起效果
建议发布新版时增加磁链，方便一些地区用户下载
v1.95 Beta8 [20220922]绿色版分流
WDMVIKNX6L6OPTTFEU3RWTZXHVN3RA3E
1.95又不能记录窗口位置和窗口布局了
建议批量下载的时候，增加一个选项，自动过滤我的共享和种子存档里已经存在的磁链
不是写的很清楚了吗，中国大陆地区限制使用下载