Von Was ist der Unterschied zwischen 127.0.0.1 und 0.0.0.0? :

Was ist der Unterschied zwischen 127.0.0.1 und 0.0.0.0?

• 127.0.0.1 ist die Loopback-Adresse (auch bekannt als localhost).
• 0.0.0.0 ist eine nicht routbare Metaadresse, die verwendet wird, um ein ungültiges, unbekanntes oder nicht anwendbares Ziel zu bezeichnen (ein Platzhalter „keine bestimmte Adresse“).

Im Zusammenhang mit einem Routeneintrag bedeutet dies normalerweise die Standardroute.

Im Zusammenhang mit Servern bedeutet 0.0.0.0 alle IPv4-Adressen auf dem lokalen Computer. Wenn ein Host zwei IP-Adressen hat, 192.168.1.1 und 10.1.2.1, und ein Server, der auf dem Host läuft, 0.0.0.0 abhört, ist er unter diesen beiden IPs erreichbar.

Was Sie tun möchten, ist, die IP-Adresse der Maschinen zu finden, die nicht 127.0.0.1 ist, was unter OS/X (und Linux) so aussehen wird:

Iota:~ bok$ ifconfig -a
...
inet 127.0.0.1 netmask 0xff000000 
...
inet 192.168.0.11 netmask 0xffffff00 broadcast 192.168.0.255

Unter Windows lautet der entsprechende Befehl ipconfig /all.

Die Adresse 192.168.0.11 ist diejenige, die Sie in Ihrer Enode-Zeichenfolge verwenden möchten, da dies die IP-Adresse der Maschine ist, die von Ihren anderen Computern in Ihrem Netzwerk kontaktiert werden kann.

Sie müssen dann Ihren Peer mit einem Befehl wie dem folgenden hinzufügen:

> admin.addPeer("enode://5d272e8bee6d29dfff6313999a4a2c3d8109ae6f3eb103480f4536c0542549b9fa12a8d8ae5ebee9c4db55cab553693b04eedbc9b29f35bbc0af1956231b42b4@192.168.0.11:30303")

Gearbeitetes Beispiel

Hier ist ein Schritt-für-Schritt-Beispiel für den Betrieb von 2 Minern auf demselben Computer unter OS/X, wobei die Miner miteinander kommunizieren. Sie sollten dies in Windows und Linux replizieren können. Sie sollten dies auch auf mehr als 2 Knoten und auf separaten Computern replizieren können.

Update 31. Oktober 2016 00:00:56 UTC Möglicherweise stoßen Sie auf ein Problem mit der DAG-Generierung, da beide Miner versuchen werden, die DAG gleichzeitig in derselben Datei zu erstellen. Unter OS/X (und Linux) wird die DAG-Datei im $HOME/.ethash. Dies ist das gleiche Problem wie in Private Chain, two geth miner on the same machine, second miner throws „panic: ethash_full_new IO or memory error“ beschrieben . Die Problemumgehung besteht darin, den zweiten Miner zu starten, nachdem der erste Miner die Erstellung der DAG abgeschlossen hat – wenn die erste DAG erstellt werden muss. In regelmäßigen Abständen muss ein neuer DAG erstellt werden, was zum Absturz eines Ihrer Miner führen kann.

Die Details:

• geth versionBerichte1.4.18-stable-c72f5459
• Dieses Beispiel wurde im Verzeichnis erstellt /tmp/Test2Miners, wobei das Datenverzeichnis von Miner Nr. 1 und das Datenverzeichnis von /tmp/Test2Miners/miner1dataMiner Nr. 2 /tmp/Test2Miners/miner2data.

• Ich habe die Datei /tmp/Test2Miners/genesis.jsonmit folgendem Inhalt erstellt:

  {
      "config": {
              "homesteadBlock": 10
      },
      "nonce": "0",
      "difficulty": "0x400",
      "mixhash": "0x00000000000000000000000000000000000000647572616c65787365646c6578",
      "coinbase": "0x0000000000000000000000000000000000000000",
      "timestamp": "0x00",
      "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
      "extraData": "0x",
      "gasLimit": "0x3B4A1B44",
      "alloc": {}
  }
  

• Ich habe /tmp/Test2Miners/testpasswordmit folgenden Inhalten erstellt:

  aaaargh
  

• Ich habe /tmp/Test2Miners/initMiner1mit folgendem Inhalt erstellt und dann das ausführbare Bit mit dem Befehl gesetzt chmod 700 /tmp/Test2Miners/initMiner1:

  #!/bin/sh
  
  geth --datadir /tmp/Test2Miners/miner1data init /tmp/Test2Miners/genesis.json
  geth --datadir /tmp/Test2Miners/miner1data --password /tmp/Test2Miners/testpassword account new
  

• Ich habe /tmp/Test2Miners/initMiner2mit folgendem Inhalt erstellt und dann das ausführbare Bit mit dem Befehl gesetzt chmod 700 /tmp/Test2Miners/initMiner2:

  #!/bin/sh
  
  geth --datadir /tmp/Test2Miners/miner2data init /tmp/Test2Miners/genesis.json
  geth --datadir /tmp/Test2Miners/miner2data --password /tmp/Test2Miners/testpassword account new
  

• Ich habe /tmp/Test2Miners/runMiner1mit folgendem Inhalt erstellt und dann das ausführbare Bit mit dem Befehl gesetzt chmod 700 /tmp/Test2Miners/runMiner1:

  #!/bin/sh
  
  geth --datadir /tmp/Test2Miners/miner1data --unlock 0 --password /tmp/Test2Miners/testpassword --mine --minerthreads 1 --port 30301 console
  

• Ich habe /tmp/Test2Miners/runMiner2mit folgendem Inhalt erstellt und dann das ausführbare Bit mit dem Befehl gesetzt chmod 700 /tmp/Test2Miners/runMiner2:

  #!/bin/sh
  
  geth --datadir /tmp/Test2Miners/miner2data --unlock 0 --password /tmp/Test2Miners/testpassword --mine --minerthreads 1 --port 30302 console
  

• Ich habe die Datenverzeichnisse initialisiert und das erste Konto (Coinbase) für beide Miner mit dem Befehl erstellt:

  /tmp/Test2Miners/initMiner1
  /tmp/Test2Miners/initMiner2
  

• Im Terminalfenster Nr. 1 habe ich Miner Nr. 1 mit dem folgenden Befehl gestartet. Ich habe die auf der Konsole gedruckten Enode-Informationen eingefügt, die auch mit dem admin.nodeInfofolgenden Befehl ermittelt werden können:

  /tmp/Test2Miners/runMiner1
  ...
  enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@[::]:30301
  

• Im Terminalfenster Nr. 2 habe ich Miner Nr. 2 mit dem folgenden Befehl gestartet:

  /tmp/Test2Miners/runMiner2
  ...
  enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@[::]:30302
  

• Ich habe die [::]in den enode-Strings durch die lokale IP-Adresse ersetzt, sodass meine admin.addPeer(...)Befehle wie folgt aussehen würden:

  admin.addPeer("enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@192.168.1.11:30301")
  

  und

  admin.addPeer("enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@192.168.1.11:30302")
  

• Ich habe die admin.addPeer(...)mit dem Enode-String von Miner #1 in die Miner#2-Konsole eingefügt.

• In der Miner-Konsole Nr. 1:

  > admin.peers
  [{
      caps: ["eth/62", "eth/63"],
      id: "b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436",
      name: "Geth/v1.4.18-stable-c72f5459/darwin/go1.7.1",
      network: {
        localAddress: "192.168.1.11:30301",
        remoteAddress: "192.168.1.11:62922"
      },
      protocols: {
        eth: {
          difficulty: 152346260,
          head: "0x8296dbd46fe12cef1415c27cb21f2ad6d70b6ee174977529eaf266c3488e6e2e",
          version: 63
        }
      }
  }]
  

  Erfolg!

• Und in der Miner #2 Konsole:

  > admin.peers
  [{
      caps: ["eth/62", "eth/63"],
      id: "dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d",
      name: "Geth/v1.4.18-stable-c72f5459/darwin/go1.7.1",
      network: {
        localAddress: "192.168.1.11:62922",
        remoteAddress: "192.168.1.11:30301"
      },
      protocols: {
        eth: {
          difficulty: 157293798,
          head: "0xd9b044d4e996407ff94b075c36b845db219078c64e7898e628983496d46067bf",
          version: 63
        }
      }
  }]
  

  Erfolg bestätigen!

• Hier ist das Konsolenprotokoll von einem der Miner:

  I1031 00:53:27.604563 miner/worker.go:435] 🔨 🔗  Mined 5 blocks back: block #1447
  I1031 00:53:27.605050 miner/worker.go:539] commit new work on block 1453 with 0 txs & 0 uncles. Took 460.253µs
  I1031 00:53:29.682117 core/blockchain.go:1001] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 12.081834ms. #1453 [3a94659b / 3a94659b]
  I1031 00:53:29.683526 miner/worker.go:539] commit new work on block 1454 with 0 txs & 0 uncles. Took 1.167337ms
  I1031 00:53:29.683565 miner/worker.go:435] 🔨 🔗  Mined 5 blocks back: block #1448
  

  Die 3. Zeile zeigt, dass der andere Miner einen Block abgebaut hat und dieser Miner den Block importiert. Die anderen Zeilen zeigen, dass dieser Miner die Blöcke abbaut.

• Um die Peer-to-Peer-Erkennung zu automatisieren, erstelle ich /tmp/Test2Miners/miner1data/static-nodes.jsonmit den folgenden Informationen (Referenz Statische Knoten ):

  [
    "enode://dd57ddfb071ab01bcb1f310601e97b06a07dc97f949e14d73dbffaf8cf60e41455a31cf671d87dc7d256d24c20b8d061296041645ac36872239c48ee74fd587d@192.168.1.11:30301",
    "enode://b47e69bed67be3f9974ce44d08b9232fd5a555a7c6d4adca5402f93406a806c7181a963c02cff991452bcaee1ab7affdbada4153d236a0017f3dd1931b9c4436@192.168.1.11:30302"
  ]
  

  und ich kopiere diese Datei nach /tmp/Test2Miners/miner2data/static-nodes.json.

• Ich starte beide Miner mit den Befehlen /tmp/Test2Miners/runMiner1und /tmp/Test2Miners/runMiner2in separaten Terminalfenstern neu und überprüfe mit und, ob sie miteinander verbunden admin.peerssind. Erfolg++.