Pi节点的Incoming和Outoging说明

一、TCP连线

首先了解TCP怎么建立连线。 通常是由一端（服务器端）打开一个通讯端（socket）然后监听来自另一方（客户端）的连接，这就是通常所指的被动打开（passive open）。 服务器端被被动打开以后，客户端就能开始建立主动打开（active open）。

当你的节点有开通PORT 31401-31403，就是扮演服务器端的角色，监听着PORT 31402，等待其他节点（客户端）发起连线。 如果有其他节点连进来，Incoming connections就会加一。

反过来，你的节点想连到其他节点，就是扮演客户端的角色，其他节点（服务器端）必须开通PORT 31402让你连进去。 如果成功建立连线，你的Outoging connections就会加一。

而Pi节点是一个点对点网络（peer-to-peer，P2P），彼此传递交易与SCP讯息，所以必然会有Outoging与Incoming连线。

二、参数

连线数分别可以通过TARGET_PEER_CONNECTIONS（out）、MAX_ADDITIONAL_PEER_CONNECTIONS（in）参数来设定，目前stellar-core.cfg都没有设定，所以是采用预设值out 8、in 64。

三、peers

core数据库内有一个public.peers表格，存放了其他节点的信息。 节点跟节点之间，会彼此分享这些数据。

你的节点会连接到哪些节点，就是由这个清单一台一台的尝试。 反过来说，其他节点会不会连进来，也是看你的节点有没有在对方的peers表格内。

（不要问怎么查这些资料，因为让一位不懂数据库的人去操作数据库，是一件很危险的事，所以我不打算写出来。 ）

一开始你的节点并不知道网络上有哪些节点，只知道核心团队的节点（在KNOWN_PEERS与PREFERRED_PEERS参数设定），所以起初数据是连到核心团队节点取得的。 当你（out）连接到其他节点（in），你只会从对方节点随机得到几笔IP资料，而不是整个peers表格。

peers表格有5个字段：

l ip：这个不用解释

l port：都是31402

l nextattempt：下一次尝试连线的时间

l numfailures：连线失败的次数，超过120次会删除

l type：有3种

n 0：还没有连线成功，会重复尝试连线

n 1：曾经连线成功

n 2：preferred peer，优先选择的节点，目前全网就三个IP：161.35.227.222、161.35.227.224、161.35.238.87。 都是核心团队的节点。

你的节点会依照nextattempt的时间顺序，不断尝试向其他节点发起连线。 如果网络不通、SYN-SENT封包根本没回应，numfailures会加一，type设定为0。 然后试下一个节点。

当全部试过后，type = 0的节点会再重试，nextattempt的时间会往后延。 而尝试失败120次（numfailures = 120）的节点，该笔数据会被删除。

如果网络有通，TCP三向交握能完成，会做身分验证，建立起连线，numfailures会设定为0、type设定为1。 但这个连线不一定会持续，可能马上就中断（peer rejected），因为你的Outoging connections已经8了，或是对方的Incoming connections已经64了，无法再容纳新的连线。

如果你目前尝试连过去的节点是preferred peer，而且有回应，但是Outoging connections已经满了，这时会自动砍掉一个Outoging connection，好让出名额。 但是也要看对方的Incoming connections有没有满，若满了，一样无法维持连线。 下图的log就是这种情况。

preferred peer的连线如果失败或中断了，nextattempt时间都会往后延，过一段时间再试，也就是说它会无限次尝试连线。 而其他节点尝试失败就算了，过去就不回头了（要等全部试完一轮才重试）。

另外，节点之间的连线一旦建立了，基本上就不会中断，可以从elapsed看到已连线的秒数。

但偶尔还是会变动，例如对方（或自己）的节点网络断线、换IP、关机，或是为了preferred peer踢掉其他连线。

四、手动连线

stellar-core http-command connect?" peer=xxx.xxx.xxx.xxx&port=31402"

上面的 xxx.xxx.xxx.xxx 是IP。

这个指令不一定成功，原因上面讲过了，可能网络根本不通，或是彼此的in/out连线数满了。

五、删除连接

先查出节点的ID：

stellar-core http-command peers?fullkeys=true

删除连接 ：

stellar-core http-command droppeer?node="GD5OPFFD2ANXGPHJ76FYAYAEMXNHRQ5JMQ5OHBWA4LJOQ3GEOGEO3EIF"

填入要中断连接的节点ID。

这样就能空出一个out连线的位置，不过通常马上就被补上了。

六、结论

如果你的Incoming connections数量很低，不是什么不正常的情况，可能其他节点不认识你（peers表格没有你的信息），或是对方尝试过连线了，但它的Outoging connections已经8个了，所以就放弃你。 只要节点在网络上挂的越久，且IP没有一直换，会有越多的节点认识你，Incoming connections数量有机会增加。

再举个例子说明，假设全网共有20000台节点，总共会发出160000（20000*8=160000）个Outoging connections，则至少要有2500（ 160000/64=2500）台节点有开通PORT 31402让其他节点连入。

如果这时候有8000台节点开PORT，则平均Incoming connections数量是20（160000/8000=20）。 20就只是一个平均值，既然称为平均值，就会有人多、有人少，所以没有任何意义，不是成为超节的资格。 只要有开PORT，就有资格被选为超节。

而在8000台节点有开PORT的情况下，整个网络最多可容纳64000（8000*64/8=64000）台节点，所以从20000台再多加44000台没开PORT的节点也没问题。

上面节点数量大家能随意替换数字，自己计算一下就了解了。 总之，不要再牵拖Docker的版本，或是下雨天了。 讨论这个数字也没意义。

七、附上老尼回答Pi友的翻译

输入连接越多，表示被访问的次数自然越多。

@尼古拉斯：“其他节点找不到您要连接的对象，并且您没有太多传入连接，这可能有多种原因。 这些原因大多与运气有关。 通常，当一个新节点尝试连接时（或者在计算机重新启动或从睡眠状态恢复后），它会尝试从它已“学习”的IP列表中查找其他节点。 如果这些节点具有可用的传入连接，则新节点将连接到它们。

 

如果没有可用的传入连接，则会将其已知节点IP列表提供给请求节点并关闭连接。 然后新节点尝试连接到这些IP并不断发现更多IP，直到它成功连接到8个节点。 由于这个过程包含一定程度的随机性，一些节点变得更加广为人知，而另一些节点则不那么广为人知。 让你的IP地址不经常改变，这对你在网络中的知名度有很大帮助。 还有一点是你与核心团队节点的距离。

 

连接到一个核心团队节点的64个节点很可能总是将其所有的64个传入连接都填满。 这是因为全新的节点不知道其他节点，它们最初尝试连接到核心团队的节点，它们可能会收到“拒绝”和已知IP的列表。 直接连接到核心团队节点上的节点的IP被这些节点明确地知道，因此也很容易被发现。 在您提问之前：哪些节点最终连接到核心团队节点是完全随机的。

 

核心团队节点相互优先，并始终相互接受。 对于其余的64个传入连接，它们以先到先服务的方式接受任何其他节点。 但是，连接到核心团队节点并不重要，区块链在任何地方都是相同的，甚至一个字节的差异都会立即触发错误，因为这会使块散列无效。 ”