比特彗星一共存储多少个DHT节点，每ip协议1280，测试版论坛上的一些讨论

小樱

比特彗星一共存储多少个DHT节点，每ip协议1280，测试版论坛上的一些讨论

测试版帖子上我的一些对话回复，下方没有对方说的内容

现在的删除dht节点做法是和种子市场一样滚动更新
来了新的节点就把已经确认失效的或者最老的挤掉出去
不存在越来越多的问题，可以让改进一下实现立即删除而不是等待满了写不进去的时候才删除，和把dht节点上限值降低到300-400个
而且关闭客户端写入dat文件的时候，不要记录确认回复以外的类型，就是没有明确收到回复都删掉，就和bt任务停止的时候删掉peer一样
bittorrent.save_connected_peers_only

你这做法其实更像DHT爬虫而不是加入去中心化网络
太过于理想化，没有考虑被其他人请求的情况
而且国内因为dns污染连不上超级节点，所以这一版也可以用node://67.215.246.10:6881/ 的形式去连接
如果离线半天，在没有长期运行的种子服务器的支持下，距离相近的节点可能就死完了，距离桶就280个了，那客户端只能请求距离更远的节点去查找，反而产生的连接数更多。还要考虑存储他人的宣告包在peer值里用于返回
如果大家都不存节点，那大概率拿到的8个节点都一样了，然后不存宣告还返回空值的peer响应

nat4网络在没有这个超级节点，或者种子内未包含node的时候永远连不上dht网络一直是0
只有公网或者nat1在下载或者上传的时候，收到其他人请求后才会新增到节点
这是因为在77这个距离上还没有发现新的节点来，只有等写满了才会删除
所以就是我上面说的，如果定时维护确认未回复可以立即删除

把这节点距离左侧的kid生成几个相近的infohash，添加到用户列表可以提升获取最近距离的新节点速度
类似这种方法
https://bbs.itzmx.com/thread-117442-1-1.html

要不然就按照我上面那份设置，让定时维护的180秒强制断开out Find_node
等于禁用每30分钟定时维护，dht.outbound_pending_request_limit 的值只给200，那么定时维护就不会进入队列，直接丢弃掉Find_node
在禁用DHT定时维护的时候，软件依旧会保持实时更新

你重新看一下bep5的dht设计规范
get_peer寻找info_hash的过程尽可能不断收拢而非直接扩散
协议设计上，peer存放的位置是靠info_hash决定的，谁的node id和info_hash更相近，就存在谁的地方
让Beta17多做一次get_peers的操作很合理，反正现在的情况就是距离最近的几个可能都没回应，可以从远一点的地方去找peer
本地看到虽然远一点，但是在其他用户的身份看，可能他自身就是最近的，这样就能扩散出去了
这可能是你理解上的扩散
比特彗星使用了280个桶而不是160个，每个桶只存10个节点，用于后续发送announce_peer宣告请求，每协议上限值为1280个
其中前150个桶用于存储与自身最近的node id来进行info_hash查找

这是两个问题，，你抓到的包是其他人请求给你的DHT包，而不是你本地客户端发送出去的DHT包
只能把1000个DHT砍成400个左右了，这样才能实现你的需求

对于提到的超级节点，其实也就是你理解的引导节点，超级代表对方为服务器身份，长期永久在线的意思
上面有提到过，nat4网络如果没有添加这些节点的时候，那么dht节点数量会永远为0
比特彗星只会在收到他人announce_peer请求的时候，仅存储自身节点id相邻的peer，总共存储100个info_hash
我觉得这样存peer并没有问题，符合bep5协议设计规范，前150个桶里用来存储的节点也是3276开头和自身节点id距离最接近
而且这一版已经不会导致连接数断网的问题了，我觉得这问题其实已经解决了

peer并没有放在桶里啊，桶里存储的是节点
这是界面上显示的两种ui，你看到界面显示的是历史总共发现到多少节点数量显示
可以说这个值是UV（UNIQUE IPS、Unique Visitor），也就是软件运行期间内有多少独立ip身份建立过连接
实际存储的活跃节点要在专家模式里面才能看到

280个桶中，后面130个桶存储的也是节点，只是存储的是距离较远的节点，比如前面150个桶存自身节点id的3276开头，这150个桶不会触发定时维护，只临时存储重启即释放
那么距离较远的这些节点就会存在后面的桶里
0001、025b、04bd、''''''、30c1、''''''
通过接收到他人announce_peer获得的peer是在单独一个新开树上存储的

我完全知道你的想法，但是你说的这个想法是纯爬虫模式，你只考虑自己对外主动发请求的情况
只存储与自身节点id距离最近的8个node肯定是不可行的，dht实际上要遵守bep的利他模式，如果不这样做，收到其他人的get_peers请求时候，如何从存储的数据中给他人返回node和peer？难不成给对方返回一个与info_hash距离更远的节点？或者你是觉得干脆不给其他人请求的get_peers做回应了？

你这套回应请求的做法除了污染DHT网络然后带来需要更多的连接数去请求外没什么价值，这就是我上面说的在你的身份看，可能你自身就是最近的，但是你实际上离info_hash还远得很
所以导致了其它客户端接收到对方回应请求后还要做一次检查判断，如果比“回复者自身 id”更接近 info_hash，则会被跳过
v2.21实现了额外做一次扩展查询，来尽可能利用这些响应不规范的节点
感觉你看不懂我在说什么，你还没理解DHT的算法原理，所以比特彗星才分了280个桶去分别存这些节点
算了，就这样吧

现在后面的130个桶里存储的是，每个桶10个，所以是1280个上限值
00
02
04
06
‘’‘’
fa
fc
fe

想要砍到300到400个DHT节点，需要改成这样，只分配32个桶来存，别分130个桶
00
08
10
18
‘’‘’
e8
f0
f8

减少桶的数量，这样才能在不限制dht.outbound_pending_request_limit的情况下实现你说的需求

之前beta的时候，我测试了几款路由在dht.outbound_pps_limit设置3000的情况，期间去tcp百度80端口也没有任何断网问题，你用的是什么路由器下才会出现断网的现象？
你确定不是运营商限制了你的连接数，你真的认为是被路由器给限制了？
如果是确定路由器限制的话，那么限制期间会打不开路由器后台，包括ping值路由器网关会变得非常高，路由器卡的就和死机了一样，我只在钛星人这款路由器上发生了这种情况，只能拔电重启路由
我的硬件有限，测试了下面四款路由在设置3000的时候均正常，启动后发送了2万到3万左右个dht包
迅捷FW300
tpAX3000
中兴AX3000
京东一代7621
除了砍DHT最大节点到300到400个左右来做优化，还能优化的就是直接禁用定时维护，让软件不在每次启动和30分钟定时发送ping、find_node包去维护节点
‘或者启动和定时维护只发ping，别发find_node去用新节点填充桶，这会导致产生几万个数据包请求，只发ping的话数据包则一般只有几百个包’
但是你在运行种子任务的时候，依旧要发送get_peers请求去查找peer，正常情况依旧会产生大约100到200个包，看来你的网络环境只能彻底禁用DHT节点了
你随便下几个种子看看能不能查找到用户，或者干脆直接删除存储的dhtnodes.dat来重新获取，安装后默认值也是没有记录任何历史节点，这样重新获取来确保当前所有节点都有效
而且把dht.outbound_pps_limit设置成2的时候，我已经测试了能正常找到peer和把announce宣告请求发出去，只是服务器上运行几千任务数多的话不行，1个任务下用2的时候没什么问题
UTP打洞主要靠PEX，也是这一beta版本优化的增强版AB反向回连，DHT主要起到辅助作用，主力打洞还得看PEX
因为双方两人不一定连接到相同的dht tracker节点上，有可能会导致互相找不到人，需要多次去更新tracker才能找到人
所以比特彗星每次更新dht tracker对10个node节点去做宣告来尽可能把自己的打洞端口扩散出去，包括最近距离的设计，实现一次连接就成功找到对方

不是。。我一直在说的就是连接数，改数据包限制也是为了压到1000连接来丢弃后续的find_node。
我觉得你没看懂我说的，现在就是因为定时维护，发送了ping请求未得到对方回应就删除了无效节点。
因为删除了这些已经失效的节点，桶里变少或者空了所以才需要去查找新的节点来进行填充回去，就这个查找过程产生了大量的连接数
这个查询并且用新节点补回去记录的过程，彗星源码里写死持续180秒，这也是我把数据包限制成2的原因之一
所以我才一直说直接禁用掉定时维护的find_node。只发送ping去删除节点，这样自然就不会发生购物新节点查找，也就没有这些连接产生了
就是因为这个定时维护删除了失效的节点，随后要用新节点补充回去。所以才会产生了大量的连接数，这么说明白了吗？所以让开发者后续版本把这个find_node查找新节点禁用就好了，只保留发ping去删除失效节点

你在专家模式中别看前面的桶，那前面150个桶是被动接收请求用的，用于存储与id距离最近的节点做get_peers返回
客户端不会主动请求这些节点，每次重启客户端都会清空这150个桶，只是挂在树上用作高速缓存，专家模式显示出来这些节点可能让你误解了
把滚动条下滑到150后面的这些桶在来观察上次发现时间
定时维护只会对280个桶中第150-280这130个桶发请求

这些是其他用户请求彗星，彗星收到的记录
协议规范上有写，DHT是双向的。不能只有你请求别人，而自身不记录其他人的数据，这会让别人请求为空这是不被允许的
包括上面 另一位网友 也提到了，在其他客户端做法也是一样的，只是他说其他客户端没有用这么多桶来记录他人数据。
总之这些桶就是个数据记录，就和左侧的值一样，里面记录的是种子特征码，你比对一下是不是发现和DHT前150个桶记录的节点id很相近。就是给其他人查找peer用的
总之你想要的改进方案大概设计方向就是。
定时维护发ping后，删除了失效节点不要立即发find_node去填满桶，而是继续持续运行了30分钟到下一次定时维护的时候，如果这个桶没有收到任何他人请求还是空的。那么在发find_node去把这个桶填满，或者永远让他空在那，直到需要了的时候在发查找请求

终末の物语

字多 不看