专用节点不断与公用节点断开连接

更新3/21/19核心开发人员已在366f64f3df266cf02a06412d6760f73626d0a2bf分支上的mainnet提交中推出了一个修复程序,该修复程序解决了我下面描述的问题.

在其中节点处于--private-mode(烘烤)的设置中 将自身连接到前端(公共)节点,则必须显式设置 您的前端节点信任您的私有节点(使用--peer参数 tezos-node或tezos-node或RPCs的配置文件)！其他, 在某些时候,您的前端节点可能会决定 断开自己与专用节点的连接,以支持全新的连接 同行.错误是存在断开连接的情况 Trusted-Private-peers(由于节点习惯于 旧连接超过新连接,但仍然如此).我们现在屏蔽了那些 连接.

本质上,有一项新功能可让您将专用节点设置为公用节点上的对等节点.与您的公共节点上的新对等节点相比,这将更有利于您的私有节点.

原始答案

这个问题从一开始就存在.问题源于私有节点与公共节点中的每个其他对等方都一样(甚至将其中一个设置为受信任).基本上,这并不是将私有节点的优先级提高,有时您的公共节点可能会确定您的私有节点"不那么有用".我的意思是,如果您考虑一下,私有节点只是卑鄙的人,并没有真正为您的公共节点做出贡献,因此您的公共节点可能会断开您的私有节点与网络中另一个节点的连接.同样,如果您的私有节点以某种方式"失当"(例如无法正常运行或占用过多资源),则您的公共节点甚至可能将其列入灰色名单,并且不允许来自您的私有节点的连接.尽管您希望将设置设置为"受信任的"应该可以缓解这种情况！

我们大多数早期面包师通过增加冗余(公共节点)数量来解决此问题,因此当断开连接时这没什么大不了的,应该早晚重新连接.我认为一般来说,这是一个好主意,因为您可能需要升级节点,并且没有冗余将使该过程更加棘手.这些天,我实际上发现我的私有节点几乎从未像早期那样断开连接.我怀疑私有节点可能具有"信誉",这与被列入灰名单相反.

在添加新功能以确保不中断优先连接之前,您的最佳选择实际上仅限于建立更多公共节点或将基础节点(可能值得信任)添加为可信节点.您可以尝试的一件事是 quicksync 或将链数据复制到您的私有节点,这样您就不会必须引导您的私有节点.在同步过程中,由于所需的资源,它可能会断开连接.问题可能是您的私有节点的工作人员,而不是您的公共节点断开了它.

Update 3/21/19 Core developers had pushed out a fix as of 366f64f3df266cf02a06412d6760f73626d0a2bf commit on the mainnet branch that addresses this issue that I described below.

In the setting where you have a node in --private-mode (to bake) that connects itself to front (public) nodes, you must explicitly set your front nodes to trust your private node (using --peer argument of tezos-node or the config file of tezos-node or RPCs)! Else, there is a chance that at some point your front nodes decide to disconnect themselves from your private node in favour of a fresh new peer. The bug was that there were cases of disconnection of trusted-private-peers (not really visible because nodes used to favour old connections over new ones but still). we've now shielded those connections.

Essentially, there is a new feature that allows you to set your private node as a peer on your public nodes. That will favor your private node over new peers on your public node.

Original Answer

This problem has been around since the beginning. The problem stems from that the private node is treated the same as every other peer in your public node(even setting one as trusted). Basically it's not prioritizing your private node higher and sometimes your public node may decide that your private node is less "useful" than others. I mean if you think about it, private nodes are just leechers, not really contributing to your public node(s) so your public node might disconnect your private node for another node in the network. Also if your private node somehow "misbehaves" such as not functioning correctly or taking up too much resources, your public node might even graylist it and not allow connections from your private node. Though you would expect setting as trusted should alleviate that!

Most of us early bakers solve this problem by increasing the number of redundancies(public nodes) so when one disconnects it's not a big deal and it should reconnect sooner or later. I think in general, this is a good idea as you'll likely need to upgrade your nodes and having no redundancy will make the process much trickier. These days, I actually find that my private node almost never disconnects unlike the early days. My suspicion is that the private node might have gain "credibility", kind of opposite of being graylisted.

Until a new feature is added that can ensure an undisrupted prioritized connection, your best options are really limited to bringing up more public nodes or adding the foundation nodes(likely trustworthy) as your trusted nodes. One thing you could try is quicksync or copy the chain data to your private node so you don't have to bootstrap your private node. It's possible that during the syncing process, it's getting disconnected due to the resources it's requiring. The problem could be your private node's workers, not your public node disconnecting it.

虽然这不能直接回答您的问题,但Kiln的功能可以在您的私有节点断开连接时通知您.

当您将Kiln配置为监视专用节点时,请在UI中包含"最小对等体".如果您的"私人节点"的对等方降至该数字以下,则会收到通知.

https://gitlab.com/obsidian.systems/tezos-bake-monitor

While this does not directly answer your question, Kiln has a feature that can notify you when your Private Node loses connections.

When you configure Kiln to monitor the Private Node, include a 'minimum number of peers' in the UI. If your Private Node's peers drop below that number, you'll receive a notification.

https://gitlab.com/obsidian.systems/tezos-bake-monitor