127.0.0.1 - - [16/Sep/2022 18:24:59] “GET /xxx.zip HTTP/1.1” 404 -
127.0.0.1 - - [16/Sep/2022 18:25:38] “GET /tracker HTTP/1.1” 200 -
127.0.0.1 - - [16/Sep/2022 18:27:30] “GET /xxx.zip HTTP/1.1” 404 -
web种子请给右键加一个立即更新的选项，失败了一直等待中
我停止再重新开始还是没有去请求web种子
收到404状态强制停止，，应该是正常的，因为web上文件不存在了
我重启任务了，应该重新请求呀
beta3新增了websocket超时处理，麻烦再试试看呢
B连到A后，A收到B的数据包后不就有B的外网端口号了吗？为啥还需要PEX？
私有种子禁止PEX，所以也无法打洞了。参见bep_0027.rst_post
看截图，是有几千个http tracker的连接在等待中，会不会是这个原因造成一直无法上传？
感谢反馈，下一版修复
程序里只能控制自己发送的UDP数据包大小，无法控制对方的。所以这里显示的只可能是自己的MTU。
回头再测试一下看看
测试了，没问题啊
请问是哪个版本？我看看错误报告
你试试任务右键菜单"更新tracker"有没有效果
有效果了，虽然还是没有倒计时显示，但是能超时了，可以显示出Tracker connection error: message timeout的错误消息，我运行一天在观察下有没有卡住的，如果没卡住就是解决了
2022-09-17 01:20:38 schedule next announce in 00:50
2022-09-17 01:20:53 Announce START: wss://tracker.openwebtorrent.com:443/announce
2022-09-17 01:20:58 Tracker connection error: message timeout
2022-09-17 01:20:58 schedule next announce in 00:20
2022-09-17 01:21:18 Announce START: wss://tracker.openwebtorrent.com:443/announce
2022-09-17 01:21:23 Tracker connection error: message timeout
2022-09-17 01:21:23 schedule next announce in 00:20
2022-09-17 01:21:43 Announce START: wss://tracker.openwebtorrent.com:443/announce
2022-09-17 01:21:48 Tracker connection error: message timeout
2022-09-17 01:21:48 schedule next announce in 00:30
剩下一个小问题，就是停止任务后，这个还会卡住在TCP连接数里，看起来是停止任务后没释放掉连接
我们的这个话题设定
A为外部网络，TCP开放
B为NAT1类型
不存在C的情况，仅AB两者实现打洞互联
以前我们研究的打洞是ABC，和现在讨论的AB自然不一样。目的就是在现有的版本PEX加强下AB两者。让A可以回连到B。
打洞逻辑是，需要有一台至少开放互联网UDP端口的服务器A
下载者B为NAT1，此时需要用UTP连接到A，然后A传给C，C在连接B实现打洞
A是fullcone不行，一定要公网开放，fullcone会导致端口被改变
你可以测试一下，A是公网IP的时候，B是NAT1，此时A收到B的数据包后，显示的是监听端口，A的用户列表中并没有B NAT1打洞后的远程端口，因为没有进行PEX交互这个端口信息。
感觉要和你说不清楚了，，，还是发个视频吧，你看下视频就知道了，A从PEX里拿不到B的NAT1的信息。只能拿到来自B的IPV6 PEX
所以我一直让你用 bittorrent.peer_dual_ip 这个的特性去实现，只做AB两者，响应自身的ip加udp端口，这个是支持对私有种子PEX的！
应该不是，，，至少目前从我的角度来看，就是启动任务，被这个元数据下载卡住了，只要这个元数据显示没了，其它的什么tracker就会立即降低下来然后开始有上传速度。
传临时视频的地方传不上了，弄个压缩包吧。
目前版本研究出来的一个超笨的方法，能缓解这个同时运行上千个上传任务做种，就是，，，关闭"BitComet启动时自动开始上次退出时正在运行的任务"功能，用"同时做种的BitTorrent任务最大数目"这个功能控制，先设置10个，然后手动一个一个点击BT任务打开运行10个，运行正常后，在全选所有任务让其进入做种排队队列。等待一段时间后，此时在把数值改成20，等不显示元数据下载正常上传后，每次多加50以此类推来缓慢增加同时任务运行数。。。直到全部上千个种子任务成功进入上传状态。
目前不知道任务列表都是上千个做种任务，这个元数据下载是干嘛的？至少这个笨方法现在可以解决这个问题，，，当然最好是等官方看看是怎么回事来优化解决下这个元数据下载。毕竟这个笨方法特别怕软件进程崩溃。。。人工去操作一次要半个小时
是的，所以建议界面改一下，改成本地上传MTU字样，，便于他人启用专家模式的时候理解。不然只有我两知道这是干嘛的，别人可能看不懂。
好的，我猜就是udp socket的问题了，要不然就是有udp发送延迟间隔导致的，，问题解决了的话，长效UDP做种上传应该也可以同时变快。理想是跨国传输UTP能达到1Gbps就行。。。至少网络调试工具实测欧洲到美国130ms的情况能达到1Gbps
刚想说看看这台服务器上崩溃原因是什么。。。一查任务日志，原来是内存不足被系统杀死。可能是这商家的vps虚拟化BUG了，那这个崩溃就无关紧要了
弹出应用程序: Windows - Out of Virtual Memory: Your system is low on virtual memory. To ensure that Windows runs properly, increase the size of your virtual memory paging file. For more information, see Help.
任务队列能不能加一个同时下载magnet的最大数目
torrent_share.max_metadata_dl_task 只对种子市场起效，对任务列表不起效，所以加个设置任务队列？
算了还是别加这个设置了，保持现在这样吧，不然死种卡住magnet，新添加的在BT任务中会一直排队等待开始下载magnet就完了。。。
我换了一个目录，解压全新的比特彗星软件，下http都正常，走代理也是正常的
之前的是1.94跟1.95
不过全新的彗星都正常，退出也不会卡灰色哪里
全新解压的比特彗星1.95，就配置了代理http下载，下啥都正常。。。
任务停止时，会先通知tracker一下，之后再断开连接。这里也做了超时处理，你等一小会儿再看看呢。
beta4改好了
我看到你的视频里23秒处，A的用户列表里出现了B，且B的远程端口10152和监听端口22223都正确显示出来了。不太明白“A的用户列表中并没有B NAT1打洞后的远程端口”是指什么？
这个我今天测试了，等了一小时都还卡在那。
会不会是因为停止的时候通知ws tracker，然后通知ws tracker连接失败，就一直重试通知导致没超时ws tracker？停止的话应该失败一次后就立即超时掉ws tracker？
吃惊，你居然还没看明白。。。要的目的是，，，A里面能PEX显示出一个B的监听端口为10152的peer(B的实际监听端口是22223，这样A发起连接才能连接到B的NAT1后的端口)，而不是我手动去添加B的IP和远程端口信息，要做成自动化。。。
两种方式应该都可以，B负责把这个NAT1后的端口信息传给A
或者直接在A里面程序代码内部处理，本地模拟PEX出来一个B的ip+远程端口。
这个10152端口怎么来的？视频38秒上有，B自身可以通过NAT类型检测获取到。
当然在A直接客户端本地取B的远程端口自动转换成监听端口new新建一个peer在用户列表里用于反向连接更好。。就是我视频操作那样手动加一个ip和端口号
这样AB才能打洞成功啊，你没看视频55秒处，A请求的是22223端口，而不是打洞端口。导致A无法连接到B，后来我1分10秒处手动 添加10152端口，就可以直接通过打洞连接到了
我想了一下，最好的修改代码方式，，是在A上做，模拟本地PEX出来一个
检测utp传输时候，如果远程端口和监听端口不一致，就本地对自身客户端PEX出来一个远程端口的ip信息。
例如A收到远程连入的utp包，远程端口10152，监听端口22223时候
就本地pex出来一个监听端口为10152的peer出来放在用户列表中，这样就自动化可以让A客户端请求这个ip端口进行反向连接B了。
应该是这个原因了，明天的版本修复一下。我这边连接这个tracker很难遇到网络卡住的情况，所以不太容易重现出来。
OK，明白你的意思了。要实现uTP打孔精细化处理，得区分peer自己报告的监听端口x、本机看到的peer远程端口y、从PEX得到的peer外网端口z。
目前的代码是只会记录x和y两个值，z保存为x。uTP peer远程连入时记录x和y。连接断开后会使用x发起uTP连接，导致A无法连接上B。
修改方法：对uTP连入过的peer，再次uTP连接使用y而不是x，仅发起TCP连接时用x。
这样做A是能反向连接上B，但B在A的用户列表里出现两次，感觉会有点混乱。
可能，，这就是博士学位的大佬吧，好像整的更复杂化了，，，让我思考一下。我还是觉得pex出来一个ip加端口比较好。这样做不用修改现有的打洞逻辑
目前版本大约十几分钟后会自动删除无效的peer，所以这个不影响，失效的会自动删掉。
还有个最重要的问题是，，，现在版本打洞成功后的传输速度不够快
是的，达不到TCP的速度
两台不存在udp qos限速的服务器UTP对拷文件
utorrent，1.5MB/s，然后发现ut的pex交互ipv6的时候居然传递了个natv6后的内网ipv6，笑死。。。
彗星最快速度170KB/s，并且正常PEX出来的IPV6地址是natv6后的公网ipv6
理想速度是要优化到200Mbps，最好可以达到1Gbps甚至更高
手动移动任务时-+似乎会占用主线程，即右键任务>文件移动到 大文件移动要花较长时间，在此期间主程序窗口和悬浮窗似乎都处于暂停状态。
使用下载目录中的 移动完成的下载 来移动文件 似乎不会出现这种情况，移动期间悬浮窗可正常更新，主窗口也可正常操作，同时不会弹出Windows资源管理器正在移动文件的窗口。
也许可以优化一下让手动移动文件时不占用主线程。
感谢反馈，已记录
为什么 下载不了呀
