现在复制一切正常了，每个地方都试过可以正常复制
这里应该可以加一个复制带文件名的&mode=download下载链接 复制按钮
不然要点击下载文件，然后在从浏览器上复制链接有点多余操作
效果很好，经过测试Beta7 是＞60分钟进行差分技术，而且间隔时间也提升到180分钟了
有一丢丢作用，但是效果不大，几千个任务只有1MB/s速度左右，你在看看？Beta7肯定还是不行的，还得继续改一下
抓包看了下是客户端不回复对方请求utp的syn包？对方一直在请求，但是多任务的情况下比特彗星不回应
是不是等待发起阻塞引起的？能不能加快一下发起速度，等待发起基本是卡住这样的，正在发起明明有1万额度，就是一直不用
反正强制UTP的话，多任务的话等待15分钟了，也下载不动几千人做种的热门种子
也不太像是等待发起阻塞引起的，因为TCP就算一直阻塞等待发起积累很多也反正一切正常
反正就是，下载方能抓到发往比特彗星做种方的utp syn包，比特彗星vps上也能抓到来自下载方的syn包，但是比特彗星就是不回复给对方utp确认包，不知道什么原因
单个peer下没什么问题，如果单任务有多个peer，或者多任务同时运行就出这个毛病了
然后就导致了，，因为不回复对方syn包，然后就没有远程连入而全是本地发起
因为等待发起阻塞，没有进入正在发起，因为不回对方syn包就收不到远程连接，也没有本地发起，所以UTP速度一直是0KB/s
打流试了一下，好像是识别不出utp syn包导致的，一开始在utp分类，过一会就识别不出来了，还是有什么黑名单？或者缓存大小用满了的限制？
哦，beta7可能修了本地发起，但是远程接收没修
只要没有因为正在发起卡住的等待发起阻塞，那么本地发起还是比较正常，就是收不到远程连入，因为客户端不回对方syn包
磁力分载点： magnet:?xt=urn:btih:O7UH3JB5KKEVCJUDO64M62GBPYWRKBGG&xt=urn:btmh:1220371a50979961a79ee8826cb135b96c5d6f92473d418ded9404c3acd5fe58df25&dn=BitComet%20V2.21%20Beta7%20%5B20260605%5D
丢tcp端口的原因能找得到吗
能知道复现方法，和改设置到600的缓解解决办法，但是这样容易导致等待发起很多
感觉和peer定时器炸了一样没成功十秒超时connecting导致的，某个线程卡住了一直不超时释放引起的
每天都要经历好多次端口丢了，要登录服务器换个随机端口在换回去才能恢复，要么就只能把发起改成600了，这样就不会丢
不过服务器都是公网ip，等待发起几十万阻塞也不是很影响就对了。。。别人发TCP请求就能上传了
Beta8 已发布，欢迎试用
v2.21 Beta8 [20260607]
核心修復：TCP發起連線過高時，TCP連接埠有丟包現象
↑這是指連接數高的時後，不會乎然出現端口封鎖了嗎?
是的，代码里加了一些错误处理，需要在高连接负载的情况下实测验证一下
v2.21 Beta8
核心修复：TCP发起连接数过高时，TCP端口有丢包现象
应该是主要解决丢包和高延迟问题，至于丢不丢tcp端口监听了，等我们来参与测试几天看看
WebUI：视频播放窗口右键菜单新增"复制视频下载链接"
我上面说的不是文件选项卡中的右键菜单吗！
就是文件选项卡下载文件，从浏览器里面复制出链接这个过程会浪费流量，WiFi的下还好
我只是想复制个带文件名的下载链接发给好友，先打开视频的这种操作也会浪费手机流量
核心修复：uTP SYN flood 防御算法导致无法接收大量连入的uTP连接
这个是禁用掉这个算法了吗，还是提高了值，这种防御感觉没有意义，和TCP一样被攻击回syncookie就行了，或者第三方防火墙来防御，软件不用带这种算法，至少tcp flood也不是把包丢了，会正常回复对方
内核参数tcp_syncookies，若启用syncookie机制，当tcp_max_syn_backlog半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。
ok…5xx個任務同時執行中
等会我上电脑测一下Beta8，我还没开始测试
长效种子的优先级应该要大于tracker?
就是在下载文件上面，，加一个复制链接
可以和优先级一样，一个箭头展开播放链接或者下载链接，主要是要有一个下载链接，播放链接倒是无所谓了，这样复制链接不会产生大量的手机流量
不过beta8看起来正常了，能看到UTP有远程接收了，就是速度还不太快
好像是单个线程的cpu用尽了，占用80%左右，还是因为触发队列发送主动降速了？强制启用UTP的时候，这个UDP传输缓冲区还没TCP大，大概在8M左右徘徊，这个是socket缓存大小吗，还是只是缓冲区大小
总之现在UTP算能用了没多大问题了，就是速度还差点意思，把那个UDP 传输缓冲区弄大点试试，多任务当前速度在20MB/s左右
肯定是现在socket缓存还是小了，导致触发队列引起的降速
UTP同样一个游戏种子单任务，500peer限制的情况，qbittorrent就能吃满单个cpu核心线程到45MB/s，Beta8 从流量图看只吃了80%，应该是socket缓存太小触发队列降速了
大概率就是缓存大小的值太小了，之前版本改的8M可能是全局的，把这个值改成32M或者64M看看？
我思考了下
不需要回复syn包的只有一种情况，当前对方处于本地客户端的 bt_banned 黑名单中，则不需要进行回应确认包
Beta8 试了一下，如果在黑名单里面，对方请求utp syn，还是会回应state确认，已经拉黑了的就不用回包了
最好的方法不是不回包，为了跟随操作系统规范化，而是对于黑名单的peer和tcp一样只回复一个fin包，对于黑名单中不回包的做法还是不太好，也不利于观察情况和通知对方已经在黑名单
也就是黑名单和tcp一样，不需要回reset，只回一个fin包断开这个syn连接就可以了
顺便一说长效种子UDP目前也没应用上ip黑名单过滤器，只有TCP才会正常回fin包
就是
完全不回syn包的情况，utp开关设置为禁用时候（当前版本已实现）
正常情况回所有syn确认包
黑名单情况回fin包
DHT网络也可以测试一下
目前发现 在禁用DHT网络后依然在发出DHT请求也许要重启软件才生效？
还有关于UDP占用连接数的问题 在程序是否有好的办法进行控制
是通过发包量控制 还是通过同时通信的IP地址数量来控制？
所以BC现在右下角显示的其实是所有DHT节点 而非活跃节点？
给DHT节点设置一个硬性上限也是个方法
不过最好还是设置一定的筛选机制以保留更有价值的节点和预防潜在的攻击
未发现，只有收到的包，没有对外发送的包，无需重启软件
禁用DHT收到大量的Get_peers和少数Find_node、ping包是正常现象
这里显示是所有历史已经成功建立过的历史DHT节点总数量，实际上只会存储1000个，专家模式下左侧可见
学qbittorrent那样取/24其中一个我肯定不太喜欢了，最好的话是随机取，不然一些dht节点永远见不到他了
正在发起大于600的时候，本地ping端口会突然出现一会高延迟或者丢包依旧存在，至于监听tcp端口是否永久丢失还要花时间去确认
没有出现在启用DHT后在禁用 依然会往外发ping包的情况？
这个显示方式可以改一改 不然数字总是越来越大
显示存储数量似乎也不太好到1000就不会变了 也许可以显示活跃节点？每次更新查询时刷新一次
如果有硬性上限的话这个其实就不太需要了
每/24取其一的方法可能和防止运营商钓鱼有关 国内倒也不太需要担心
抓包中并没有看到禁用后还对外发dht包的情况，你那难道能抓到对外发dht包的情况吗
统计中显示应该不用改了，毕竟给专家看的历史成功连接节点也更符合人类可读吧，改了后就不就丢失这个显示了，而且分成两行显示不同数值可能更让人看不明白
按照之前找出来的复现方法，试了几次没复现丢tcp端口监听了，虽然突然高延迟的情况还存在
软件全选任务停止，批量替换tracker清空等待发起，开启任务就能概率复现
如果在运行几天没丢tcp端口就是确定解决了
beta8对比之前版本，发现启动任务的时候，等待发起里面好像不会积累几万的peer了，等待发起能不能加快一点移动到正在发起，只有20到200个左右。。。我1万配额，明明几秒解决等待发起的问题，非要阻塞住卡个几十分钟去
我说的是右下角端口监听旁边的显示DHT数量
节点数量越来越多看起来有些奇怪
启停任务和替换tracker似乎会引起界面短暂的卡顿
这个延迟可能与此有关
我说的就是这个啊，统计里面显示也是这个，其它软件也类似显示的记录了历史数值，活跃节点要去专家模式左侧看（对应上方qps）这不同显示是两种概念了
一个是实时活跃，一个是历史总计
这是永久丢失tcp端口的快速复现方式（不需要长时间运行就能复现）
后来经过各种测试，发现和正在发起的值有关，＞600就会出现高延迟丢包，甚至更严重直接丢失整个tcp端口
这也是当前beta8更新正在测试的内容
总之丢包高延迟依旧存在，不过好像没有永久丢tcp端口了（等我运行久一点确认）
有個問題…同時運行的任務數太高的話，操作介面會卡…然後一堆連線就中斷了，如果把bitcomet縮到系統列就正常運作了
system.compact_memory_interval
突然卡界面把这个改成0就好了，不然会定时压缩内存到C盘上，会引起卡顿
