比特彗星一共存储多少个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的情况下实现你说的需求