在系统中，节点间无法毗连通信听起来有些奇怪，但凡是有两个因素会导致这个环境产生：一个是网络地点的翻译（Network Address Translation，简称NAT），另一个是防火墙。

当IPFS网络在2019年增长了30倍后，我们遇到了一个很大的问题：溘然间IPFS DHT表中的许多节点都呈现了网络地点翻译的问题，这导致许多节点无法毗连，从而使得整个系统的质量极大低落。

留意：节点在客户模式和处事器模式之间的自动切换是默认的设置选项。但用户也可以将节点牢靠配置为客户模式。

同理，假如一个处事器发明本身无法被其它节点毗连了，它就会从处事器模式切换回客户模式。

AutoNAT成果以前只在某些节点中被激活。但AutoNAT的成果利用得越来越多，它辅佐了我们清理系统中无法毗连的节点，这使得AutoNAT的利用越来越泛起漫衍式状况。

因此，我们此刻在所有的IPFS节点中都提供了AutoNAT成果，不外这个AutoNAT成果有必然的限制。

为了处理惩罚这个问题，我们此刻回收的步伐是假如有节点被猜疑无法毗连，就直接忽略这个节点，而且也勉励一些节点本身退出系统，假如它们本身猜疑本身大概无法被其它节点毗连了。

为了做到这点，我们利用了libp2p的AutoNAT成果，它雷同一个漫衍式STUN层，让节点奉告系统中其它节点本身的网络地点以及本身是否可以被毗连。

在前面的分享中，我们提到在IPFS 0.5版本中，DHT有了较大的改造，并扼要先容了DHT在IPFS中的浸染以及其在IPFS中的实现方法：Kademlia。

为了审慎起见，一个节点必需要验证它是否可果真被毗连，假如它被验证既支持客户模式也支持处事器模式则它就可以被插手到DHT表中作为节点。

不外假如不将该选项配置为“dht”（自动切换模式）或“dhtclient”（牢靠配置为客户模式）则大概极大低落系统的机能。因此对此选项的配置必然要小心。

在前面的文章中我们先容到Kademlia的主要特性是所有的对等节点都可以由小到大被内联集成起来，这个特性很是重。

参考链接：https://blog.ipfs.io/2020-07-20-dht-deep-dive/

好比在几个非对称网络中有节点X、Y、Z，他们彼此之间能互通并与A也相联络，，但A却无法联通X、Y、Z。同样，假如节点A和B有网络地点翻译方面的问题，它们也无法彼此毗连通信。

假如在这个进程中节点0找到节点33，并要节点33奉告下一个节点时，节点33却奉告节点0一个已经无法毗连通信的节点，那节点0再走下去就是个死胡同了，这不只会导致网速变慢，还会导致全网数据的碎片化（有些节点可以毗连而另一些节点无法毗连）。

基于AutoNAT的模式切换很是有用，我们但愿只管用它把系统中无法再毗连的节点排除去。

本日我们先容Kademlia如那里理惩罚无法毗连的对等节点。

只有一个节点可以被毗连它才从客户模式（client mode，在客户模式中节点可以向DHT表格发送查询请求，但无法对查询请求作出回应）切换为处事器模式（server mode，在处事器模式中节点既可以向DHT表格发送查询请求，也可以对查询请求作出回应）。

举例来说，当对等节点0在寻找对等节点55的一路寻址进程中，它一边找会一边知道本身离方针越来越近。要做到这一点，系统中的每个节点都要能相互通信，奉告对方本身的身份。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。