想搞清楚 BitTorrent DHT 节点到底是怎么跑起来的最快的办法不是去啃 BEP 文档而是自己动手起一个。我用 Node 生态里的bittorrent-dht这个库搭过很多次从本地笔记本到云上的一台小机器都试过环境齐备的情况下从装依赖到节点进入 ready 状态5 分钟都用不了10 分钟是留足了踩坑余量的说法。这件事的价值在于它会把你对 P2P 网络的理解从“听过”推到“见过”你能亲眼看到路由表一层层被填满看到 find_node 的返回值从空数组变成一串紧凑编码的节点看到 get_peers 真的从某个陌生节点那里拿回了 peer 列表。本文适合三类人一是想补分布式系统实战经验、但不想一上来就啃论文的开发者二是做网络观测、内网自动化、分布式键值存储实验的技术同学三是纯粹对“无中心节点怎么找到彼此”这件事好奇的爱好者。我不打算讲成大而全的理论课重点是把一个可运行的节点搭出来再把它跑稳中间那些文档里不会写的细节——端口、NAT、token 过期、路由表长不起来——我都会按实际遇到的情况讲清楚。所有代码都可直接复现依赖的库是公开的开源实现你可以照着抄。需要提前说一句DHT 本身是一套分布式的节点发现与数据定位协议把它当作分布式系统实验床、内网服务发现、网络拓扑观测都很合适至于用它做什么请自行评估所在环境的要求和内容合法性本文只讨论协议与工程实现。1. 先把 DHT 想明白它到底在解决什么问题1.1 从中心 tracker 到全分布式发现早期的 BitTorrent 下载依赖 tracker客户端启动后先连 tracker 报到tracker 把当前在线的 peer 列表返回给你你再挨个连过去。这个模型很好理解但有一个天然的脆弱点——tracker 挂了、或者它拒绝服务整个 swarm 就散了。DHT 的出现把这块能力彻底拆解掉了不再有任何中心者记录“谁有这个文件”所有参与节点共同维护一张巨大的分布式路由表任何一个人只要知道文件的 infoHash就能沿着一张类似“地址簿中的地址簿”的网络逐步逼近那些记录着 peer 信息的节点。这套机制最早由 Kademlia 算法支撑BitTorrent 把它落地成 BEP5 规范。理解它的关键不是背协议字段而是理解一个心智模型整个网络有一个 160 位的地址空间每个节点被分配一个 160 位的 ID两个 ID 之间的“距离”用按位异或计算。异或有一个很好用的性质——它构成一个度量空间满足对称性和三角不等式而且距离大小和二进制前缀长度直接挂钩。这意味着每个节点都能用一棵虚拟二叉树把整个地址空间切成很多段离自己近的段 subdivided 得更细离自己远的段保持粗略。这就是路由表的雏形。打个生活化的比方你要找一个住在某城市某区某街道某门牌的人。你不会拿着全国地图一格格翻而是先判断“在哪个省”再“哪个市”再“哪条街”。DHT 里每一次 find_node 查询本质上就是问一个节点“你认识离目标 ID 更近的人吗”对方从自己的路由表里挑出 k 个离目标最近的节点给你你再去问这些人。每一跳都让查找范围缩小至少一半160 位空间意味着最多十几跳到二十跳就能收敛实际网络里因为节点进出频繁通常再多几跳。1.2 路由桶、k 值和节点 ID 的生成策略路由表在实现上被切成若干“桶”bucket。每个桶对应一段地址空间桶里保存若干个节点信息每个桶能装的节点数上限就是 k 值。BEP5 建议 k8主流实现里取值在 8 到 20 之间都有bittorrent-dht用的 KBucket 参数默认是 20。也就是说理论上路由表最多能存 160 个桶乘上 20但实际很少有人能把表填满——大多数节点的路由表也就几十到几百个条目这是个很健康的量级内存占用微乎其微。桶的维护规则里有个很讲究的设计新节点进来时如果对应桶没满直接放进去如果满了老实现会把桶劈成两半新实现里更常见的是“先 ping 一下桶里最老的节点活着就保持原样、把新来的丢掉死了才替换”。这个策略乍看很反直觉——新节点明明更可能在线为什么优先保留老的原因在于防攻击和稳定性如果无脑接受新节点攻击者只要不停地用伪造 ID 的节点来轰炸你的路由表就能把你好不容易建立起来的邻居关系冲干净进而污染你的查找结果。优先保留长期存活的节点让路由表具备惰性是抵御这类攻击的核心手段。节点 ID 的生成也有讲究。最省事的做法是随机生成 20 字节这也是bittorrent-dht的默认行为。但如果你有长期运行的打算随机 ID 每次重启都变路由表就白建了。更稳的做法是从一个固定种子派生或者干脆把 ID 持久化到磁盘上——只要 ID 不变别的节点路由表里存着你你重启后很快就能被重新发现。我在一台长期跑观测脚本的机器上就是先把 ID 存到文件里重启直接读回来首轮 bootstrap 后能立刻恢复上百个邻居。1.3 一个节点日常在处理的四类请求跑起来之后你的节点会不停收到 UDP 报文全部用 bencode 编码请求类型归到底就四种。ping 是最简单的存活探测问一句“你还在吗”回一句“在”。find_node 是路由查询我给你一个目标 ID你从路由表里挑 k 个离它最近的节点返回给我。get_peers 是核心业务查询我给你一个 infoHash如果你有对应的 peer 列表就直接返回 values如果没有就返回离这个 infoHash 最近的节点列表和一个 token。announce_peer 是登记环节我告诉网络“这个 infoHash 我有资源我的端口是 X”你验证我带来的 token 合法之后把这条记录存下来。token 这个设计值得单独说一句。它由节点自己按一段时间内的 IP 派生出来有有效期announce_peer 必须带上从 get_peers 那里拿到的 token 才被接受。作用是防止有人拿你的节点当免费的公告板猛刷垃圾数据——你没有先做过合法的查询就拿不到有效 token。这个机制在实际运营中非常重要否则一个开放 UDP 端口的节点几天之内就会被各种扫描和滥用流量淹没。节点返回的节点列表用的是紧凑格式每个节点 26 字节20 字节 ID 加 4 字节 IP 加 2 字节端口。这种紧凑编码在 UDP 报文里非常节省空间一个包能塞几百个节点信息。理解这个格式对后面排查问题很有帮助——如果你直接打印返回值看到的是一坨十六进制得自己按 26 字节切开才能读。2. 环境准备与依赖选型倒计时开始2.1 运行环境和网络条件的核查清单动手之前先把几件事确认掉能省掉后面一大半的困惑。第一是 Node 版本bittorrent-dht现在主流的版本要求 Node 14 以上我建议直接用 18 或 20 的 LTS老版本在 Buffer 处理和事件 API 上有差异容易踩坑。第二是网络出口DHT 全部走 UDP很多公司网络或者公共 Wi-Fi 会拦掉非标准端口的 UDP 出站表现就是节点启动了但 ready 事件死活不触发。第三是入站可达性这一点决定了你的节点是“只能查别人”还是“别人也能查你”。关于第三条得讲清楚一个容易被忽略的事实DHT 节点即使在完全无法被动接入的情况下也能工作因为它是主动发查询出去的响应会沿着 NAT 建立的映射回来。但这种“半残”状态的节点路由表里永远只有自己主动联系过的那些规模小、查询质量差。想让它真正成为一个健康的网络公民最好有一台有公网地址的机器或者在路由器上把 UDP 端口映射做好。我见过太多人抱怨“节点数一直上不去”最后发现只是防火墙没放通 UDP 入站。还有一个容易漏的点bittorrent-dht默认会监听 6881 端口的 UDP。这个端口在很多环境里被别的程序占着尤其你机器上装过别的下载工具的话。启动前用netstat -anu或者ss -lun看一眼能避掉一个经典报错。2.2 几套成熟实现的横向对比不同语言生态都有成熟的 DHT 实现选哪个主要看你后面想拿它干什么。实现形态语言/形态上手成本适合场景需要注意bittorrent-dhtJavaScript / Node极低一个包搞定快速验证、观测脚本、原型实验纯 JS 实现大流量下 CPU 占用偏高libtorrent 绑定C 核心 多语言绑定中等需要编译环境需要完整 BitTorrent 协议栈时体量大配置项多学习曲线陡Go 生态实现Go低单二进制部署长期驻留的观测节点、服务端程序需要熟悉 Go 的并发模型自研最小实现任意高但收获最大深度学习协议细节至少要花几天处理边界情况如果你是第一次接触我强烈建议先用bittorrent-dht把流程跑通——它把 bencode 编码、KRPC 收发、路由表维护全都封装好了暴露出来的 API 就是几个方法和几个事件。等你对整套流程建立了直觉再去看别的实现或者自己写一版效率会高得多。至于 Python 那边的绑定如果你本来就在用 torrent 相关的工具链直接拿现成的绑定也能跑但依赖体积明显更大启动也慢。选型时还有一条隐性标准库的维护活跃度。DHT 协议本身早就稳定了但运行环境在变比如 Node 的新版本时不时会改一些底层行为长期没人维护的库会在这些地方莫名其妙地挂掉。选之前翻一下最近一年的提交记录比较保险。2.3 一个最小可运行节点的完整代码环境好了就直接上代码。先初始化工程装依赖mkdir dht-node cd dht-node npm init -y npm install bittorrent-dht然后写index.jsconst DHT require(bittorrent-dht) // 如果你要长期运行把 id 存下来复用能显著提升路由表恢复速度 const dht new DHT({ // 不传 bootstrap 时库会使用内置的一组公共引导节点 time: 30000 }) dht.on(ready, () { const addr dht.address() console.log([ready] 节点已上线监听于, addr.address, addr.port) console.log([ready] 当前路由表节点数:, dht.nodes.toArray().length) }) dht.on(node, (node) { // 路由表新增节点时触发高频事件正式环境记得做采样打印 }) dht.on(warning, (err) { console.warn([warning], err.message) }) dht.on(error, (err) { console.error([error], err.message) }) dht.listen(6881, () { console.log([listen] UDP 端口已绑定, dht.address()) })跑起来node index.js正常的话几秒钟内能看到 ready然后路由表节点数会从 0 慢慢涨到几十上百。第一次跑的时候盯着这个数字从 0 跳到 8、跳到 30、跳到 90 的感觉比看任何文档都直观——这就是你的节点正在被网络接纳的过程。3. 核心实现拆解从 bootstrap 到稳定在线3.1 bootstrap 到底发生了什么这一环最值得展开。所谓 bootstrap就是你的节点刚上线时谁也不认识需要先找几个“熟人”打听打听。库内置了一组公共引导节点你启动时会先向这些地址发 find_node 请求查询目标填自己的 ID。对方不认识你但会从自己庞大的路由表里挑出一小批离你 ID 最近的节点发给你你把它们塞进自己的路由表再挨个向这些新节点发同样的查询。这个扩散过程是几何级数的几轮之后就稳定下来。手动控制 bootstrap 也不难构造时传bootstrap: false然后在需要的时候调用dht.bootstrap([{ host, port }, ...])。这个能力在几种场景下很有用一是在内网做实验不想让节点跑到公网上去二是你已经有几个已知的稳定节点想定向加入某个小型网络三是你怀疑内置引导节点在某个网络环境下不通想换个入口试试。需要注意的是bootstrap 不是一次性的动作长时间运行的节点在路由表缩水时应该重新引导我一般会在节点数低于阈值时触发一次。还有一个常见误解bootstrap 完成后节点就算“联通”了。不是的。ready 事件只代表第一次引导流程走完此时路由表可能还很稀疏。真正意义上的“健康”要看节点数是否持续增长、能不能成功完成一次 get_peers 查询。3.2 主动填充路由表lookup 的正确用法dht.lookup(target)是个被严重低估的方法。它会针对目标 ID 发起一次完整的迭代查找过程中会访问大量节点顺手把它们都放进你的路由表。刚启动的节点路由表很薄跑几次针对随机 ID 的 lookup节点数往往能翻好几倍后续的查询成功率也明显提升。代码很简单function warmUp() { // 生成一个随机 20 字节目标触发一轮完整查找 const target require(crypto).randomBytes(20) dht.lookup(target, (err) { if (err) return console.warn(lookup 失败:, err.message) console.log(查找完成路由表节点数:, dht.nodes.toArray().length) }) } // 启动后延迟几秒等首轮 bootstrap 稳定 setTimeout(warmUp, 5000)我做长期观测的时候会把它挂在一个定时器上每十几分钟跑一次随机 lookup效果相当于给路由表做定期维护。但别太频繁——每次 lookup 都是几十上百个 UDP 包跑太狠会被对方节点或者你自己的网络设备限速。而且这种行为在公共网络上要注意分寸做实验可以搞成高频扫描就不合适了。注意lookup的完成回调触发时机是“迭代过程结束”不代表一定找到了东西。DHT 里“找不到”是极其正常的结果不要把它当失败处理。3.3 get_peers 与 announce_peer 的实操细节这两个是业务侧最常用的接口。先说 get_peersconst crypto require(crypto) // infoHash 必须是 20 字节的 Buffer不是十六进制字符串 const infoHash Buffer.from(0123456789abcdef0123456789abcdef01234567, hex) dht.get_peers(infoHash, (err, peers) { if (err) return console.error(查询失败:, err) if (!peers || peers.length 0) { console.log(这个 infoHash 目前没有已知 peer) return } peers.forEach(p { console.log(peer:, p.host, p.port) }) })这里最容易踩的坑是 infoHash 类型。很多地方给你的 infoHash 是 40 位十六进制字符串直接传进去会报错或者静默失败必须先转成 Buffer。我在第一次写的时候卡了快半小时就因为这个。announce_peer 稍微复杂一点因为它必须带 token而 token 只能从 get_peers 的响应里拿dht.get_peers(infoHash, (err, peers) { // get_peers 的内部实现会带上 tokenannounce 时库会自动复用 dht.announce_peer(infoHash, 6881, (err) { if (err) return console.error(announce 失败:, err.message) console.log(登记成功) }) })bittorrent-dht把 token 的获取和复用封装起来了你不用手动管。但如果是自己实现协议就必须注意 token 的有效期——过期了要用新的 get_peers 换硬拿旧 token 去 announce 会得到 bad token 的响应。这个机制在用抓包工具看流量时会非常明显值得亲手抓一次看看。3.4 事件模型与可观测性的搭建bittorrent-dht的事件不多但每一个都有用。ready 前面讲过是启动标志。node 事件在路由表新增节点时触发频率很高正式环境里千万别直接在里面写 console.log一天下来日志能撑爆磁盘正确做法是累加计数或者按比例采样。peer 事件在别人向你的节点 announce 时会触发如果你想让节点真正参与网络可以监听它并记录一些统计数据。warning 和 error 是两个不同级别的问题——warning 大多来自收到了格式不对的报文属于正常噪音error 才是真的需要处理。我第一次跑的时候被 warning 刷屏以为出大事了抓包看了才发现是别的节点发来的报文里带了我不认识的字段库做了容错处理但顺手报了个警告。所以对 warning 的正确态度是看一眼消息内容如果是解析类的忽略即可如果是网络类的比如发送失败再深入查。4. 把节点跑稳参数、端口与防火墙4.1 端口选择与 NAT 穿透的现实6881 是个约定俗成的端口但不是必须的。选端口的思路是避开系统保留段避开已经被占用的最好选一个你自己记得住的。云服务器上要注意安全组规则UDP 入站必须显式放通很多人只配了 TCP 就以为万事大吉。NAT 的问题更现实。家庭宽带绝大多数不是公网地址而是运营商的大内网你的节点发出的查询能出去、响应能回来但外部节点主动来找你就进不来。这会导致两个现象路由表能长但长到某个数就停了get_peers 的成功率明显低于公网节点。解决方案按投入排序有这么几种把节点部署到有公网地址的云主机上最省事在路由器上做 UDP 端口映射需要路由器管理权限在 IPv6 环境下直接监听全局地址如果运营商给了 IPv6这是最干净的方案。怎么判断自己是不是公网地址看路由器 WAN 口拿到的地址属于哪个段就能大致判断或者用几条命令对比本机地址和外部看到的地址是否一致。这部分我不展开重点是你要意识到“节点跑起来了”和“节点能被外部访问”是两件事。4.2 资源占用与并发控制很多人以为跑一个 DHT 节点很吃资源实际测下来一个正常参与的节点内存占用在几十 MB 量级CPU 在空闲时几乎为零。真正吃资源的是高频查询。如果你写了个脚本疯狂发 lookupCPU 会飙起来因为每个报文都要 bencode 编解码纯 JS 实现的编解码在高压下并不便宜。我的经验值是单节点每秒几十次查询完全在舒适区上百次就要开始关注事件循环的延迟了。长期运行的话建议加个简单的限流控制并发查询数在几十以内。另外要留意路由表的上限——按 k20、160 个桶算理论上一千多个节点但实际很难填满。如果你看到节点数异常大比如上万那多半是哪里统计错了因为路由桶结构本身有上限约束。还有个小细节长时间运行后内存会缓慢上涨原因通常是各种事件监听器没清理干净。如果你在循环里给 dht 加监听记得对应的移除操作。我踩过一次一个定时任务每分钟加一个 peer 监听器却从不移除跑了两天内存翻了三倍。4.3 日志与关键指标的设计想长期观察节点状态光看控制台输出不够。我一般会定期采样这几个指标写进日志路由表节点数、已处理请求数、收到的 peer announce 次数、最近一次成功完成 lookup 的时间戳。这几个数字组合起来基本能判断节点的健康状况——节点数稳定增长说明网络接纳正常请求数有波动说明在参与announce 次数长期为零说明你的节点根本没被外部访问到。let stats { nodes: 0, peers: 0, nodesSeen: 0 } dht.on(node, () { stats.nodesSeen }) dht.on(peer, (peer, infoHash, from) { stats.peers }) setInterval(() { stats.nodes dht.nodes.toArray().length console.log(JSON.stringify({ t: Date.now(), ...stats })) }, 60000)这份日志格式很朴素但够用。等你需要画图的时候直接把 JSON 行喂给任何分析工具都行。5. 常见问题排查实录5.1 症状对照表从现象快速定位原因下面这张表是我这几年攒下来的覆盖了绝大部分新手会撞上的情况。排查顺序建议从第一行往下走因为前面的问题会掩盖后面的问题。现象可能原因排查动作处理方式启动后迟迟不触发 readyUDP 出站被拦、引导节点不可达手动 ping 一个已知地址看响应换网络环境或换一组引导节点ready 触发了但节点数个位数不动入站 UDP 未放通、处于对称 NAT 后用外部端口检测服务验证 UDP 可达性放通防火墙或部署到公网机器节点数正常但 get_peers 永远返回空infoHash 类型不对或网络里确实没数据打印 infoHash 的 byteLength 是否等于 20补上十六进制到 Buffer 的转换报 bad token 错误token 过期中间间隔太久检查 get_peers 到 announce 的时间差重新查一次拿新 token启动即报 EADDRINUSE端口被别的进程占用ss -lun查占用换端口或停掉占用进程warning 大量刷屏收到畸形报文属于正常噪音看具体消息内容是解析类错误就忽略可关闭对应日志内存持续上涨事件监听器泄漏、日志缓冲未清理观察堆内存曲线检查监听器数量定时移除无用监听限制日志缓冲CPU 占用异常高查询频率过高、编解码压力大统计每秒报文数加限流降低并发查询5.2 两个我踩过的坑值得单独说第一个坑是关于“看起来在跑其实没跑”。有次我把节点部署在一台新机器上ready 正常触发日志正常输出节点数也涨到一百多一切看起来完美。但挂了两天announce 次数一直是零。抓包才发现这台机器的 UDP 入站被安全策略拦了——出站查询照常回包靠 NAT 映射也能收到所以路由表能长但外部节点主动发来的查询全部被丢弃。这个状态用常规指标完全看不出来必须专门看“别人有没有主动找过你”。第二个坑是节点 ID 不稳定带来的隐性成本。一开始我用的就是默认的随机 ID每次重启路由表都从零开始建还得跑几次 lookup 才能恢复到能用的状态。后来把 ID 持久化下来重启后第一轮 bootstrap 就能被老邻居认出来恢复时间从几分钟降到几十秒。如果你打算长期运行这一个小改动收益非常明显const fs require(fs) const path ./node-id.bin let id if (fs.existsSync(path)) { id fs.readFileSync(path) } else { id require(crypto).randomBytes(20) fs.writeFileSync(path, id) } const dht new DHT({ nodeId: id })注意nodeId必须是 20 字节 Buffer传字符串会报错。这个字段名在不同版本里可能有差异装完之后翻一眼类型定义最保险。5.3 抓包是最后的真相所有排查手段里抓包是唯一能给你确定答案的。Wireshark 里给 UDP 加个端口过滤能看到完整的 KRPC 报文。重点看三件事请求有没有真的发出去、响应有没有回来、回包的内容结构对不对。我遇到过一次诡异的问题节点能发出查询但收不到响应抓包发现是对端把一个格式不合规的响应发过来了库在解析阶段直接丢弃。这种情况换任何配置都没用只能接受它就是网络噪音。抓包还有个额外好处你会亲眼看到 token 是怎么流转的、紧凑节点格式长什么样、一次 lookup 到底发了多少个包。这些直观印象对理解协议的价值远超读十遍规范。6. 节点跑起来之后几个不容易踩雷的用法6.1 把它当作分布式系统实验床我个人觉得DHT 节点最有价值的用途是当教学和实验的载体。Kademlia 里的几个核心设计——异或距离度量、路由桶的惰性更新、迭代式查找、token 防滥用——都是分布式系统里反复出现的模式。你可以在自己的节点上加日志观察一次查找的完整收敛过程记录每一跳的目标距离变化用数据验证“每跳至少缩小一半查找范围”这个结论。这种亲眼见证比背诵算法描述有效得多。具体做法很简单包装一下dht.find_node把每一跳返回的节点距离目标 ID 的异或值算出来打出来function distance(a, b) { // 异或距离越小的前导零越多距离越近 const len Math.min(a.length, b.length) let acc 0n for (let i 0; i len; i) { acc (acc 8n) | BigInt(a[i] ^ b[i]) } return acc }跑几次就能画出距离随跳数下降的曲线非常直观。这也顺便帮你建立了对“160 位地址空间”的实际尺度感——那个数字大到用普通整数根本存不下得用 BigInt。6.2 内网服务发现的一个轻量思路DHT 的键值定位能力不止用于文件索引。BEP44 引入了在 DHT 上存储不可变数据和可变数据的能力前者是把一段内容哈希成 key 后存储后者允许带签名更新。bittorrent-dht提供了put和get两个方法用起来像极了一个极其简陋的分布式 KVdht.put({ v: Buffer.from(node-a:192.168.1.10:8080) }, (err, hash) { if (err) return console.error(err) console.log(已写入key , hash.toString(hex)) }) dht.get(hash, (err, res) { if (err) return console.error(err) console.log(读回:, res.v.toString()) })必须说明的是这个 KV 非常不可靠——数据只存在愿意帮你存的那些节点上随时可能消失写入也不保证成功。所以它只适合“丢了也无所谓、重新写一次就行”的场景比如内网里几个服务互相播报自己的地址或者给一套自动化脚本做轻量的状态广播。真正要做可靠的服务发现还是得上专门的注册中心。我拿它做过一个小实验几台机器把各自的角色标签写进 DHT管理脚本定期读一遍做拓扑汇总跑了几周读写成功率大概在七成左右作为玩具够用作为生产工具远远不够。6.3 网络拓扑观测与合规边界最后一个用法是做观测。你的节点每收到一个查询都能看到对方的地址和 ID长期收集可以做不少有意思的分析节点的地理分布、ID 的分布是否均匀、每天活跃时段的变化。这类数据对研究 P2P 网络的健康度有帮助。但这里有一条必须守住的线。收集到的 IP 和端口属于别人网络环境的信息只做聚合统计是一回事把明细公开或者拿去关联个人身份是另一回事。我的原则很明确只留聚合数据明细在内存里处理完就丢日志里绝不落盘原始 IP。另外观测脚本的查询频率要克制不要让它变成对别人网络的骚扰。做实验和搞破坏之间,区别往往就在频率和意图上。我在一台长期运行的机器上按这个原则跑了几个月积累了十万级的匿名统计数据用来分析节点在线时长的分布挺有意思——大部分节点存活时间以小时计能连续在线超过一周的比例小得惊人。这个数据也反过来解释了为什么 DHT 的路由表需要那么强的惰性更新策略网络上绝大多数成员都是路过的。如果你也打算搭一个长期节点我的建议是先从小规模开始把日志和指标跑通观察一两天再决定要不要加大频率。跑稳之后你会发现这套东西真正的乐趣不在“搭起来”的那十分钟而在你盯着路由表数字慢慢变化、偶尔从某个陌生节点收到一条 announce、然后意识到自己刚刚真的参与了一个没有中心的网络。那种感觉很具体比任何架构图都真实。
实践)
