search

PBH-BTN / PeerBanHelper

自动封禁不受欢迎、吸血和异常的 BT 客户端，并支持自定义规则。PeerId黑名单/UserAgent黑名单/IP CIDR/假进度/超量下载/进度回退/多播追猎/连锁封禁/伪装检测 支持 qBittorrent/Transmission/Deluge/BiglyBT
GNU General Public License v3.0
539 stars 15 forks source link

[TODO]规则引擎重构 #156

Closed Ghost-chu closed 1 week ago

Ghost-chu commented 2 weeks ago

目前的规则引擎是按模块设计的，然而，有时需要多条件联合检查时（如：需要PeerID+客户端名称+端口 同时满足特定条件)时，将无法实现。

PluieM commented 2 weeks ago

提供一种方案思路： 1、在客户端把接收到的Peer清单维护成一个FIFO的队列，队列中的元素 { PeerInfo, isBanned，bannedBy, LastLiveTimestamp }，banPeer的指令对应为对队列中的Peer的isBanned标记位的操作 2、正常Peer断开连接超过一定时间从队列中剔除 3、恶意Peer被ban超过一定时间后从队列中剔除

这样不仅可以满足这个需求，同时也可以大幅减少像订阅规则这种相对固定的匹配规则导致的计算量，因为在规则发生变动之前是完全可以根据（队列中存在该Peer&&该Peer未被ban）的判断来跳过这次匹配的

Gaojianli commented 2 weeks ago

提供一种方案思路： 1、在客户端把接收到的Peer清单维护成一个FIFO的队列，队列中的元素 { PeerInfo, isBanned，bannedBy, LastLiveTimestamp }，banPeer的指令对应为对队列中的Peer的isBanned标记位的操作 2、正常Peer断开连接超过一定时间从队列中剔除 3、恶意Peer被ban超过一定时间后从队列中剔除

这样不仅可以满足这个需求，同时也可以大幅减少像订阅规则这种相对固定的匹配规则导致的计算量，因为在规则发生变动之前是完全可以根据（队列中存在该Peer&&该Peer未被ban）的判断来跳过这次匹配的

其实不对，正确的做法是将规则进行编译为有限状态机，这样对于固定的匹配规则其消耗时间就是可计量的了

PluieM commented 2 weeks ago

提供一种方案思路： 1、在客户端把接收到的Peer清单维护成一个FIFO的队列，队列中的元素 { PeerInfo, isBanned，bannedBy, LastLiveTimestamp }，banPeer的指令对应为对队列中的Peer的isBanned标记位的操作 2、正常Peer断开连接超过一定时间从队列中剔除 3、恶意Peer被ban超过一定时间后从队列中剔除 这样不仅可以满足这个需求，同时也可以大幅减少像订阅规则这种相对固定的匹配规则导致的计算量，因为在规则发生变动之前是完全可以根据（队列中存在该Peer&&该Peer未被ban）的判断来跳过这次匹配的

其实不对，正确的做法是将规则进行编译为有限状态机，这样对于固定的匹配规则其消耗时间就是可计量的了

你说的对，规则确实应该抽象成有限状态机。我前面的描述有点问题，我想表达的意思更多是指规则匹配结果的应该有一个针对全部规则模块可见的队列来保存和复用。

Ghost-chu commented 1 week ago

重构已完成