The executable to run a bootnode is bootnode
. In Ubuntu, this installed alongside /usr/bin/geth
in /usr/bin/bootnode
.
You will have to generate a key to run your bootnode:
user@Kumquat:/tmp$ bootnode -genkey nodekeyfile
user@Kumquat:/tmp$ cat nodekeyfile
3bed8e0fa771475049cddac0fcc20a6cf1005e271e2b12ef339f213218b2dbdb
user@Kumquat:/tmp$ bootnode -nodekey nodekeyfile
I1001 23:17:42.874776 p2p/discover/udp.go:217] Listening, enode://d3b75b24a4fd718b1358d28ba576b2e98f73a7465326c4504f21cc0d124466a91919de18fb72a634f9108f0eedd5ef943aea5c250b41c974c4a7fb7c159b9968@[::]:30301
In a separate window, I ran the netstat
command to view the UDP 30301 port that bootnode
is listening on:
user@Kumquat:/tmp$ sudo netstat -anp | grep boot
[sudo] password for user:
udp6 0 0 :::30301 :::* 8317/bootnode
This bootnode
program only serves as a bootstrapping node and will not provide any blockchain data transfers.
You should now be able to use enode://d3b75b24a4fd718b1358d28ba576b2e98f73a7465326c4504f21cc0d124466a91919de18fb72a634f9108f0eedd5ef943aea5c250b41c974c4a7fb7c159b9968@[::]:30301
as your geth --bootnodes
parameter value, where you replace [::]
with the IP address of your bootnode computer.
Update
If you have issues getting the peer-to-peer discovery to work, add the --verbosity 6
before the console
parameter of geth
. You should see the communications to the bootnode in action.
You can also add the verbosity parameter to the bootnode
command:
user@Kumquat:/tmp$ bootnode -nodekey nodekeyfile -verbosity 9
I1001 23:17:42.874776 p2p/discover/udp.go:217] Listening, enode://d3b75b24a4fd718b1358d28ba576b2e98f73a7465326c4504f21cc0d124466a91919de18fb72a634f9108f0eedd5ef943aea5c250b41c974c4a7fb7c159b9968@[::]:30301
I1001 23:39:12.546003 p2p/discover/udp.go:453] >>> 192.168.1.14:54991 discover.pong
I1001 23:39:12.546145 p2p/discover/udp.go:521] <<< 192.168.1.14:54991 *discover.ping: ok
I1001 23:39:12.546226 p2p/discover/database.go:183] failed to retrieve node b68ed408e685e6dc75ea457b65f945fa2c6f2171c8bfaf26e32d6362c3ebe9ed3ef3aeb682991e3a01250f93f2a68ea8ca1a98676e669cc007ed227c35d7c3f1: leveldb: not found
I1001 23:39:12.546337 p2p/discover/table.go:473] Bonding b68ed408e685e6dc: known=false, fails=0 age=409813h39m12.54632801s
I1001 23:39:12.547012 p2p/discover/udp.go:453] >>> 192.168.1.14:54991 discover.ping
I1001 23:39:12.549582 p2p/discover/udp.go:521] <<< 192.168.1.14:54991 *discover.pong: ok
I1001 23:39:12.556974 p2p/discover/udp.go:453] >>> 192.168.1.14:54991 discover.neighbors
I1001 23:39:12.557059 p2p/discover/udp.go:521] <<< 192.168.1.14:54991 *discover.findnode: ok
And the latest P2P discovery protocol documentation can be found at RLPx: Cryptographic Network & Transport Protocol.
Best Answer
So we actually very, very rarely completely exploded. During big ICOs for instance we were seeing 200k transactions being sent via the MEW node in a single hour, which is about 55 TX/sec. Each transaction consists of:
Loading balance
Loading token balances
Getting network gas price (we no longer do this)
Estimating gas (each time the user changes a field)
Getting the nonce of an account
Actually sending the TX
This had us receiving ~1M requests/hour, or 277 req/s. We have seen DDOS (or dapps) hit as much as 4M requests/hour (but not for a sustained period like an ICO).
During these situations we don't necessarily crash we just have massive latency as it moves through the queue. At some point, depending on your infrastructure, you will obviously completely run out of memory and explode or refuse to accept incoming connections or timeout before it can process anything.
There is also a very large difference between the calls themselves. 5M getBalance requests is different than getting the TX hash or broadcasting a transaction or getting the nonce.
There is also a very large difference between internally attempting to getBalance or sendRawTX and accepting these calls via API / JSON RPC. Locally, we have been able to process 10k transactions in ~7sec. If we dump 10k txs in API, it takes more like 40 seconds to return the TX hash to 10k different users, as long as there aren't 10k other calls thrown in there for confusion.
So, to answer your question, the number of open files in your config file is likely the max right now, which is likely 1024. 😉
The bottlenecks appear at various points, not always the node itself. We have hit bottle necks with TX pool size, CPU, open files, and more. We currently run 10 nodes: 5 geth and 5 parity. For whatever reason, a few of us are having issues with huge latency spikes on Parity itself right now.
If you want to dive deeper, https://github.com/MyEtherWallet/docker-geth-lb