|
July 24, 2017, 08:48:41 PM |
|
1) Yes, that does it.
2) The less RAM/threads you got, the longer it takes for the DB to build. As for how little RAM you can get away with, you're looking at:
a) Core eats around 3GB RAM. Most of its memory use to maintain the UTXO set, the bigger that gets (and it ought to with SW), the higher that requirement will go.
b) ArmoryDB needs ~1GB RAM tops to just run maintain itself and run the client, but it will be looking at ~2.5-3GB by default to bootstrap. There are cli args to reduce the resource cost of the bootstrapping part if you are running on a tight budget. You can also split the setup where you let Core bootstrap first, shut it down, let ArmoryDB bootstrap then run the whole stack to avoid concurrent costs.
c) Core needs space for blockchain data and its DB. 200GB should get you an extra year from August 1st maybe?
d) Armory's DB is fairly lean. Currently it's <1GB. 5GB should last you at least till 2020.
e) Assuming you have lots of swapping space, you could get away wtih 2GB RAM on a very lean setup. 4GB is better, 8 is what I would recommend.
3) Right now you want client and server in lock step. Once this stuff congeals (it came out in 0.95, we're at 0.96, so maybe another version or 2?), the requirement should loosen.
4) It would hold the address script hashes you register with it from your clients. That's WO data only, no chaincode.
5) This is the network stack:
a) Node talks to other nodes over the WAN.
b) DB tries to talk a node on localhost only (hardcoded), through 2 different ports, one for P2P layer, one for RPC. RPC is not mandatory but preferable.
c) DB listens on localhost (hardcoded again) as a FCGI service. Local clients connect directly through that interface, remote obviously clients can't, therefor you need you put a web daemon in front of that FCGI service (since it's works over HTTP) to allow for clients to connect to a remote DB.
d) Client connects to the DB/port you give it. By default it looks on localhost. There is currently no encryption of the client to DB layer, that stuff is for a future release. If you want to use TOR on top of the HTTP daemon, you would need to turn your daemon into a hidden service, run Tor on the client machine and somehow tunnel the daemon over localhost:port for the client to figure that out. Or you can VPN into the server VM. If the VM is a guest on your machine, you can just connect to the DB over whatever IP:port the VM makes itself visible as.
Neither the client nor the DB use nor need the WAN. All phone home code has been removed since 0.94. All possible operations that would open a browser to an external link (that's only to show you your tx on a blockchain explorer) come with a warning message box (in case you miss click it).
|