上面说的轮询怎么样好做吗，，，不然只有首次发起是TCP，后续重试的时候永远是UTP，，，然后这个utp打孔能不能，仅在私有起效果？BT下有性能更好的PEX，不需要这个影响效率。
不是，，，你没发现吗，上个版本的测试贴我发了APP图，BT任务大小，和详情里文件大小，都不一样，好歹要一样吧?
我指的不是和电脑上的文件大小不一样，是APP内几处不同界面的地方，显示的文件大小不一样
beta12测试了启用bittorrent.utp_after_holepunch可以正常超时了，实测大约71秒左右会断开超时，时间不固定，偶尔有一些100多秒的，不过多等一会都会超时了
然后问题是，，只要TCP失败一次后，他后续永远只会utp发起，而且都是正在UDP打孔。。没有UTP直接连接状态，要让他轮询一下。
既然network.max_udp_pkt_per_sec提高了，network.max_connecting_connections要不要也提高一下，，虽然目前挂1000种子的情况下1W还用不完，但是万一有人挂1W个种子呢！
再者就是，，，提高UTP的传输速率？utorrent上传给比特彗星1.5M ，比特彗星上传给比特彗星170K
webgui界面127.0.0.1响应时间40ms视乎也可以优化下到1ms
下载BT任务的时候，是不是也有检查磁盘队列情况之类的？能不能把它放在磁盘写操作缓冲区里，不然看流量网卡会断断续续的，观察了下特别是4MB小区块的任务容易出现这种现象，猜测是要等待下载完成的区块写入完成才继续后续下载？好像更大可能性是检查了磁盘活动队列，因为使用PrimoCache延迟写入优化后依旧发生这种现象。
HTTP任务就优化的很好，不会出现BT那种情况。网卡流量下载是一条直线维持不会断流
v1.95 Beta12 [20221011]绿色版
435fad37f0f3a572aa5fd7c007018b7cb53cc6c4
beta13 已改进
是的，这几处调用的代码并不相同。后续修复
BT分块检查完hash后是放到工作线程写盘的。网络流量断断续续，是只连接了1个用户的情况吗？
BT任务种子连接6个peer用户，试了下删除其它5个，只保留1个也是会出现这种断流情况。
磁盘写操作缓冲区是有动，但是经常跳成0，找一下问题在哪优化解决试试？以前版本的http下载也有这种掉速到9KB/s然后下载速度不工作的情况，这个BT任务应该是类似相同的原因。
测试关闭bittorrent.utp_after_holepunch和开启的时候，都可以正常轮询了
设置里下方的描述可以适当改一下了
测试正常，显示正确
其实我觉得长效上传的缓存效率目前不高，，，因为我最多大概就占用2G过，然后看读取缓存次数和实际读盘次数都是100多次每秒，疯狂读盘，不知道能不能一次取16M做缓存内存块来优化。
例如一个100MB文件完整为1234567891011121314151617181920------100
用户访问目标为其中22-100的位置，那么就取17-32，33-48—以此类推作为缓存块？
用户后续访问第23，24，25，26个MB时候，直接调用17-32的缓存结果，这样应该有效提高命中率？
一个100MB的文件作为长效上传，16MB一个区块，实际读盘应该为7次。
其中一台服务器，，，命中率不超过40%，，现在的长效缓存，反正感觉很奇怪
试了一下改出问题了，破坏了之前的Beta成功版本，现在私有种子用你做的这套打洞方案，ABC打洞会拿不到peer，应该在加个判断
BT任务下为了PEX效率，不发起UTP打洞
TCP→UTP→TCP→UTP→→→→→→这样？
或者保持现有的TCP→UTP→UTP打洞→TCP→UTP→UTP打洞→→→→→有点浪费UDP请求次数和dead等待重连握手的30秒左右延迟时间，个人觉得BT下没必要保持UTP打洞发起
或者你觉得BT任务下直接不发起不太优雅的话，做个高级设置开关，，，UTP打洞应用类型 三个选项，全部 仅BT 仅PT
私有种子下需要先发起
TCP→UTP打洞→UTP→TCP→UTP打洞→UTP→→→→→这样？
私有种子下必须先发起UTP打洞一下，不然直接建立UTP成功了，拿不到第三者的peer ip，，也就没法打洞了，所以还是PEX效率高，可以在已经建立UTP通讯的peer上实时交互用户列表。。
包括AB打洞，我发现异常断开UTP连接产生 seen 状态的，回连会使用 正在UDP打孔 发起，会连接失败重试一两次，这是错误的，对于异常断开的 seen 状态应该直接UTP发起回连。
改出的BUG包括，手动添加用户，设置为发起为UTP打孔，，，也失效了
所以你偏要用这个打孔来打洞！不但效率慢，而且代码量改的太复杂了容易出BUG！又得修复了
v1.95 Beta13 [20221012]绿色版
5b644be4f2e159adc7a4e84f7536a38d87db9aa7
统计里这个可以每30分钟保存一次流量数据到xml里吗，不然运行十几天后，比特彗星停止任务的时候崩溃了，重启后流量数据就没了。
上面发的那些问题解决，UTP传输速率，和打洞出BUG了，，还有就是同时打开1000个以上任务TCP发起卡住很长一段时间的问题，，解决就为1.9x版本画上句号，完美版了
上千个任务刚启动的时候，看到有很多的等待，TCP正在发起要不要开大？一段时间后倒是好了，1W够用
啊？1.94能看的来着
截图又炸了
1個讚
怎么下载啊
国内网络无法下载
更新到1.95后下载几乎为0，以前好歹还有个几十 几百K的流量，现在基本是几K了，请教各位前辈咋整？？？
期待正式版