今晚试一下，感觉就算成功了也不是希望所想要的样子。。
bittorrent.utp_after_holepunch 启用后（自动），私有种子确实是打洞成功了，不过等待了2分钟左右才开始响应UDP打孔的来源。。。论效率完全不如PEX
还有，，我想起来我为什么把bittorrent.utp_after_holepunch 禁用掉了，因为这个功能有BUG，之前反馈过你没修复，打开后connect不会超时了，一段时间后会积累几百万的connect状态。
改成BT那样的PEX不行吗？
Content not available in your region.
所在地区内容不可用……蛋疼……没有电脑端的梯子……
其他客户端都遵循私有种子不支持PEX，彗星还是遵守规范比较好。至少打洞协议已经能用了，虽然慢一点。
感谢反馈，我再测试一下
之前说的web gui界面，statistics里能不能显示完整点？比如说udp传输的utp等等，都没显示出来，同步一下主界面的最新显示？能展开的都默认展开一下。。DNS故障这个可以不用，可有可无，其他的都需要展开
几十上百个BT任务做种的情况，如果开启utp很容易导致触发udp全局每秒发起限制引起UDP内存阻塞导致泄漏内存引起软件崩溃。而且传输速率也不快，，就几十KB/s
论坛有很多类似的帖子，，，就不一一列举了
https://www.cometbbs.com/t/bitcomet%E8%87%AA%E5%8A%A8%E9%80%80%E5%87%BA/77628/15
改成10000确实不堵了。。。
DNS故障是啥呀
失效的tracker
统计里的流量数据，，如果停止所有任务后，退出比特彗星，等待五分钟发现比特彗星卡在进程退不掉，任务管理器杀死后流量数据会不保存，这个好修一下嘛
那bittorrent.utp_after_holepunch可以仅在私有种子下生效吗。。BT种子下不需要这个
提个建议，“.bc_bak”文件，双击（也就是“选择用bitcomet打开”）的时候，直接打开“导入界面”，这样能减低导入操作难度（不过话说回来，本来导入也不难，只是有些小白不会用而已）
感谢反馈，应该是显示出bug了
是在往硬盘写数据，还是CPU占满在清理种子列表数据，还是单纯的死锁了？
可以考虑默认连接顺序修改为TCP失败后 → uTP直连失败后 → uTP打洞
感谢建议
这是在主线程调用win32api进行文件操作造成的卡顿，后续准备改成任务完成后移动文件的方式，使用工作线程。
任务管理器观察到硬盘没有动静，CPU在做什么不知道，，，反正吃满一个核心，猜测是和之前说的那个正在发起http tracker卡住的问题。（退出时候要和tracker汇报停止） 估计是这个原因导致退不出。。。
可以改成这样，还有启用这个高级选项后UTP不超时问题。。
有没有1.95的豪华版，安装就有种子市场的
对于utp也可以加个高级选项？
bittorrent.utp_udp_send_queue_threshold
如果队列达到设定值100，新收到的utp包就丢弃不回复。。。防止 UDP 传输缓冲区 内存泄漏
dropped queries
