비공개 노드가 공개 노드에서 계속 연결 해제됩니다

19 년 3 월 21 일 업데이트 핵심 개발자는 아래에서 설명한이 문제를 해결하는 366f64f3df266cf02a06412d6760f73626d0a2bf 브랜치에 대한 mainnet 커밋 시점에 수정을 푸시했습니다.

--private-mode에 노드가있는 설정 (베이크) 자신을 전면 (공용) 노드에 연결하는 경우 명시 적으로 설정해야합니다. 프라이빗 노드를 신뢰하는 프런트 노드 (--peer 인수 사용) tezos-node 또는 tezos-node 또는 RPC의 구성 파일)! 그밖에, 어느 시점에서 프론트 노드가 결정을 내릴 가능성이 있습니다. 새로운 새로운 것을 위해 개인 노드에서 자신을 분리하십시오. 동료. 버그는 연결이 끊어지는 경우가 있다는 것입니다. 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