Sparkle Public Tracker 欢迎各位尝试测试

简单介绍一下,如果你是 PeerBanHelper 的用户,你大概已经听说了 BTN 网络这个东西。BTN 网络通过在用户的设备上安装 BTN 客户端,客户端收集下载器上的 Peers 数据和封禁数据等信息,上传 BTN 网络,并生成一个在线规则。

例如坛内的: 适用于 BitComet 的 BTN 外挂脚本,实时动态反吸血BT BAN 以及 PBH-BTN 的 PeerBanHelper

但目前的方式有一个缺点,就是吸血 Peer 必须首先连接到使用了上面的程序的用户的下载器上,才能被探测到。而且经过几次技术对抗后,现在部分吸血 Peer 的连接经过伪装,很难和正常 Peer 进行区分了。

所以我们在今年早些时候开始了 Sparkle Public Tracker 项目,它与 Sparkle BTN 网络深度集成,并在近期服务器搬家到乌龟壳后开始公测。

在除了提供基本的 BT Tracker 功能(帮助您和他人连接)以外,Sparkle 还会将 Tracker 的数据与 BTN 网络集成,使用两侧的数据一起帮助反吸血,帮助识别伪装客户端。

Sparkle Public Tracker 支持这些 BEP:

  • BEP-3 - The BitTorrent Protocol Specification
  • BEP-23 - Tracker Returns Compact Peer Lists
  • BEP-24 - Tracker Returns External IP
  • BEP-31 - Tracker Failure Retry Extension
  • BEP-48 - Tracker Protocol Extension: Scrape

除此之外,Sparkle 完全支持 IPV4 和 IPV6 双栈网络和多 IP 汇报。并且支持记录种子的下载次数(而不是返回0)。

注:Sparkle 目前不支持加密扩展和 UDP 扩展,这是刻意的。Sparkle 不是一个匿名 Tracker,我们确实会记录活动数据。但记录的相关数据仅用于反吸血和安全用途,不会分享给第三方。


如果要在 BitComet 中使用 Sparkle Public Tracker,您可以:

(1) 添加到现有种子任务中:

打开种子的 “追踪器”,并在菜单中选择 “编辑 Trackers…”

复制粘贴下面的文本到“服务器列表”中,并确定保存。

https://sparkle.ghostchu-services.top/tracker/announce
|https://btn-prod.ghostchu-services.top/tracker/announce
|http://sparkle.ghostchu-services.top/tracker/announce
|http://btn-prod.ghostchu-services.top/tracker/announce

列表中显示添加的追踪器时,则操作完成。

(2) 添加到自动添加列表,这样以后添加新种子时,就会自动使用 Sparkle Public Tracker 了。


对于其它下载器,请添加下面的地址到您的下载器中即可(请不要在地址之间添加空行,因为这四个是一组服务器,添加空行会导致下载器总是请求所有地址,增加负载):

https://sparkle.ghostchu-services.top/tracker/announce
https://btn-prod.ghostchu-services.top/tracker/announce
http://sparkle.ghostchu-services.top/tracker/announce
http://btn-prod.ghostchu-services.top/tracker/announce
5個讚

试了下tracker用不了,浏览器打开发现502错误

目前我认可的搭建公共tracker程序只有opentracker,其它任何一个都是垃圾,现有的程序都试遍了,tracker服务进程一跑起来,50 http并发就崩溃

1個讚

应该好了,Docker 网络没配好

偶尔挂掉也算正常,现在接着 CI,有的时候提交的代码可能本身就有问题

看起来没啥压力,不是并发导致的问题。

00:56 重新配置了 docker 容器,单独划了个网络

测试了,现在工作正常了,还可以,ipv4请求后可以正常返回ipv6列表

同时对A和AAAA还要明天把 network.dns_query_cache_ttl 改成10在测一下,因为hosts被DNS缓存的原因,期间重启了客户端peerid发生了改变,现在IP被记录在tracker服务器上,没办法用停止从列表删除

1個讚

话说 BitComet 退出是不是不会通知 Tracker 种子的 STOP 事件?
我注意到其他客户端退出的时候都会等待一会儿(通知 Tracker),但是 BitComet 它是真的直接就退出了。

直接退出会通知,但是这个通知stop过程不会太长,如果这段时间内因为网络或者tcp队列原因没发送成功请求,一段时间后会强制执行退出避免退出后常驻后台进程只能任务管理器杀死的现象

1個讚

我傻了,换个种子测不就行了
测试同一个peerid可以正常响应A和AAAA 通过

发现的问题有一个,客户端自身没办法从tracker获取响应自身ip和端口,peer回应数为0,不应该过滤,找一个只有自己的种子,右键更新tracker始终回应为0

问题2,,,正是上面说的问题,客户端发送event=stopped 后,客户端B请求tracker依旧响应客户端A的ip,没有从服务器中删除

这个我看看要不要加一个 PeerID 更改检测。
理论上同一个 IP 的同一个端口跑不了两个 BT 客户端。(很极端的情况比如一个只跑BT一个只跑UTP除外)

这个是刻意过滤掉的来着,因为 tracker 响应会返回 external ip 字段(bep_0024.rst_post)。
重复返回似乎意义不大

例如网吧同ip出口,局域网中两个人用迅雷下同一个种子的话找不到对方,因为迅雷不支持lsd,只能通过tracker返回,对于自身ip不应该过滤

目前 Tracker 的实现是根据 PeerID 来的,如果 PeerID 不一样,相同 IP 还是会返回的

select t from TrackedPeer t where t. torrentInfoHash = ?1 and t. peerId <> ?2 order by RANDOM() limit ?3;

排除掉自身(根据 PeerID)有助于客户端搞清楚真实用户的数量。

1個讚

试了下peerid改变确实可以返回自身ip,那没问题了

这人的tracker就不行,,永远不会返回自身ip
udp://explodie.org:6969/announce

问题2,,,正是上面说的问题,客户端发送event=stopped 后,客户端B请求tracker依旧响应客户端A的ip,没有从服务器中删除

我刚刚检查了一下,是命中了瞬时缓存。

瞬时缓存指的是一个生命周期非常短的缓存(只有 3 秒),用来减轻 Tracker 负载。
这样如果有客户端瞬间并发(或者是非常热门的种子)就会直接命中缓存,避免数据库产生负载。

命中缓存会直接返回缓存结果,但 announce 过程会在异步慢慢处理。

1個讚

我也认为应该过滤请求者的 Peer 信息

我自己有多个出口 IP,就经常遇到下些冷门种子一直在自己连自己
虽然这个 Tracker 过滤了,其他 Tracker 还是会返回


就是类似这种 Tracker,用 IP 而不是 PeerID 来区分
如果用两个不同的 IP 去请求,还是会左脚踩右脚

这其实是算还行的,我见过返回全是 CloudFlare IP 的……

把随机差分也加上吧,返回一个随机值,可以提高性能,让CPU更平滑
https://bbs.itzmx.com/thread-106752-1-1.html

大部分tracker程序确实都不支持cdn,,,不是返回127.0.0.1就是返回CF的ip,opentracker也是2024年4月11日 发布的版本才开始支持传递真实ip,找作者修了好久才支持上CDN
https://bbs.itzmx.com/thread-102765-1-1.html

我看下。


PS. 实际上不加也没问题,Sparkle 在用 Java 21 的虚拟线程特性。这种大量连接进来并不会创建的大量的线程一路耗尽线程池的问题(一个系统线程可以处理大量的虚拟线程,特别是 I/O 类型的,而不会产生昂贵的开销),announce 也是异步的,peers 也有瞬时缓存……

如果出现问题,我这里的图表应该能看出就是了。

NPHP 主要是 PHP 性能本身就差一点,NPHP 的代码也很古早,再加上它的 Announce 逻辑太重了还没有异步。

要不我调度我tracker服务器10%的访问流量上去你那试试看性能,这个优化代码难度不大能加的话最好加了,可以让客户端每个BT任务的时间都错开,避免同一时间请求到tracker服务器中,特别咱们比特彗星用户经常挂几万个种子的都有