Tengo 3 nodos ejecutándose en una red privada.
Después de hacer esta pregunta , agregué manualmente node1
como peer to node2
y node3
, por lo que mi red se ve así:
_______
---------> | node2 |
/ |_______|
v
_______
| node1 |
|_______|
^
\ _______
---------> | node3 |
|_______|
Dejé los nodos ejecutándose anoche, pero alrededor de las 10 p. m. (BRST), node2
y node3
dejé de escuchar node1
( admin.peers
estaba vacío), mientras node1
todavía estaba conectado a ambos ( admin.peers
contenía 2 elementos), pero no obtuve ninguna interacción.
¿Es posible que esto sea un problema con el protocolo Ethereum o sería otra cosa?
Estoy ejecutando los nodos en la misma máquina física, pero en diferentes máquinas virtuales. Esas máquinas virtuales se han Ubuntu 12.04
instalado.
Las máquinas virtuales se ejecutan en un CentOS con VMWare vCenter.
Resumen
Hubiera esperado que los parámetros de los nodos de arranque permitieran que el nodo 2 y el nodo 3 encontraran el nodo 1, el nodo 2 y el nodo 3 y luego que todos los nodos mantuvieran sus conexiones entre pares.
Por Henrique Barcelos
el problema de , parece que esta configuración no es estable en una red privada que ejecuta los nodos en una máquina virtual.
La alternativa de usar static-nodes.json
no parece proporcionar una conexión estable.
La siguiente configuración a probar es usar trusted-nodes.json
y especificar el --maxpeers
parámetro
A continuación se muestran los pasos que estamos tomando para resolver el problema.
Un problema interesante.
En cuanto a la probabilidad, diría que es muy poco probable que este sea un problema con el protocolo Ethereum, ya que es lo suficientemente robusto para Internet.
Ha declarado que su hora está sincronizada con la hora de la red. Este parece ser un problema que se encuentra regularmente y es por eso que hice la pregunta anterior.
Veamos su configuración.
Pregunta. ¿Está ejecutando otros nodos de la red principal de Ethereum dentro de su red privada? La razón por la que pregunto esto es que puede haber un conflicto con el puerto de red 30303, en referencia al primer enlace de su pregunta.
Desde el primer enlace de su pregunta, está iniciando sus instancias de geth en los diferentes nodos con el siguiente comando:
geth --verbosity 4 --autodag --nat any --genesis /opt/blockchain/genesis.json
--datadir /opt/blockchain/data --networkid 4828 --port 30303 --rpc
--rpcaddr 10.48.247.25 --rpcport 8545 --rpcapi db,eth,net,web3,admin
--rpccorsdomain '*' --fast --mine --ipcdisable
El nodo 1 se ha configurado como su nodo de arranque. Los nodos 2 y 3 tienen el archivo /opt/blockchain/data/static-nodes.json con la siguiente información:
["enode://{node1publickey}@{node1ip}:30303"]
La información en /opt/blockchain/data/static-nodes.json en 5. anterior coincide con la información de inicio en la instancia de node1 geth que se muestra usando el comando admin.nodeInfo en la instancia de node1 geth.
...
enode: "enode://{node1publickey}@{node1ip}:30303",
...
¿Es esto correcto?
--nat any
parámetro --networkid
es único de la red principal "1" --port 30303
debería ser un problema a menos que esté ejecutando otros nodos Ethereum de red principal dentro de su red, y aun así no debería ser un problema, ya que estará en una IP diferente --rpcaddr
debe ser la dirección IP de cada máquina. El nodo 1 debe tener la dirección IP del nodo 1. El nodo 2 debe tener la dirección IP del nodo 2 y el nodo 3 debe tener la dirección IP del nodo 3. --rpcport
, --rpcapi
y --rpccorsdomain
no debería afectar la conectividad de su red. --fast
El parámetro ya que su cadena de bloques debe ser pequeño de todos modos, ya que es una cadena de bloques de testnet interna. --mine
y --ipcdisable
no deberían afectar su conectividad.--bootnode
parámetro y probar el /opt/blockchain/data/static-nodes.json
método en 5. arriba en los nodos 2 y 3. Ejecute esto por un tiempo y esperemos que no tenga interrupciones de conectividad. Podemos tachar esto de la lista si aún tiene interrupciones de conectividad.Añadido a continuación el 04/12/2016:
Henrique Barcelos
ha estado usando el static-nodes.json
método para que los pares se encuentren, pero las conexiones entre pares se interrumpieron. He sugerido intentarlo trusted-nodes.json
, ya que estos especifican nodos de pares confiables para conectarse y no estarían bloqueados por los --maxpeers
límites de conexión.static-nodes.json
opción no se conectaría a menos que agregue un --maxpeers
parámetro distinto de cero, aunque --maxpeers
está destinado a 25 por defecto.node1
es el nodo de arranque, estoy pasando su enodo a través --bootnodes
de node2
y node3
, pero no haystatic-nodes.json
--nat
el valor predeterminado es "cualquiera" de acuerdo con los documentosstatic-nodes.json
archivo en node2
y node3
, con una matriz que contiene el enodo de node1
. Dejaré los nodos funcionando durante la noche y mañana comentaré los resultados aquí (estoy en GMT-0300)static-nodes.json
ayudó, pero no puedo estar seguro.--maxpeers
el valor predeterminado es 25 y solo tengo 3 nodos en ejecución:/--dev
, ¿debería estarlo?Developer mode: pre-configured private network with several debugging flags
.--dev
modo. Los nodos se han comportado bien durante la noche, sin divergir hasta ahora.admin.verbosity(6)
para rastrear los intentos de conexión P2P.trusted-nodes.json
? ¿Tienes que reiniciar geth para que use la lista de enodos?
privacidadisahumanright.eth
Henrique Barcelos
JackWinters
Henrique Barcelos