比特彗星批量删除peer列表,防止几十万用户列表导致拥堵

#1

问题,,peer列表一直保存,重启软件多达数天也不会释放
1
比特彗星批量删除peer列表,防止几十万peer用户列表导致拥堵

^.*(port=".*").*$

torrent目录下xml文件,记事本++全部匹配替换空即可

1個讚
我的报BUG列表专用贴 1.57开始
#2

连接失败的peer任务停止时不会被保存,下次任务启动也不会再出现了。
连接成功过的peer,本次任务停止时会被保存,下次任务启动若连接失败也会被丢弃。

#3

你确定现在逻辑是这样的嘛,,dead算是连接失败嘛?要不要在试试?

#4

或者你说的只是针对下载状态?对做种状态无效?

#5

咦,好像是没问题,,,可能因为我之前是直接退出软件没有停止导致的吧,而且我软件基本上24*365开着的。。

#6

可以帮忙写个失败多少次自动删除掉吗。。之类的,或者失败的一段时间后超时删除,因为正常都不会停止任务

#7

好的,长期做种的情况确实需要定期自动清理。

#8

新版已增加无效peer自动清理操作,连接失败3次以上一小时后清理

#9

@ wxhere15


看看代码是不是缩水回去了

#10

对了,,我发现这些几万的种子,在disconnetct里面,有几个种子里面基本全是new add,是不是卡new add和这个也有关系,堵住了?并且这些种子,停止不会释放。停止重新开始。。还是好几万的peer列表

#11

是的,目前只有dead peer会被清除

#12

那可以关联new add问题了。。。如果new add直接发起请求,就不会有这种毛病了

#13

new add目前的处理应该是每隔几十秒尝试连接几十个,以避免低档wifi路由器处理不过来卡死。如果需要的话,也可以考虑加个高级设置提高连接并发数。。。

#14

肯定很需要啊。。。网络路由器性能不用担心。50块包邮家用的TP处理这点连接都不会存在问题,,
就是软件代码负载能不能承受才是个情况,比如说炸了未响应界面。。

#15

对了,要不然,,在停止重新开始的时候,
同时也把new add也清了吧,仅保留已连接的peer就行了,其他状态统统不要,
banip状态的话,,这个状态的留着吧,不然重新开始要重新ban掉麻烦点

1個讚
#16

好的,很好的建议

#17

嗯,毕竟重新开始连接tracker会拿到新的一份newadd,老的就清了吧,,免得堵着

#18

新版加了高级设置项:bittorrent.save_connected_peers_only,启用后不再保存 new added peers

#19

如果是长期运行,,有什么好办法嘛,这个设置是停止时候不保留吧?

#20

长期运行,new added应该都变为dead,最后被清理掉。现在的问题似乎是new added始终没有尝试连接。我再想办法测试测试。