Do adults get deranked ? Or is it that a node can’t see itself ?
When I look into ~/.local/share/safe_vault/root_dir/members.json I can’t see my IP, while I see it on yours.
That would mean that only elders can see adults. That’s plausible because elders need to know them to distribute chunks to them but adults don’t.
So, with 5mins to spare I just tried to fire up CLI to connect to this… wondering why I would need a
~/.config/safe_vault/vault_connection_info.config
to exist for the CLI to know where the network is…
Then because this from a cold start, and needing that file I start the vault and fails as expected with the router I have… but before it failed I’m surprised no vault_connection_info.config was created.
So, unclear to me when vault_connection_info.config is created… and why that is needed for CLI to find a network… does cli not have a config that can note the location??.. I did put one instance of the network to ~/.config/safe-cli/config.json but it didn’t work… perhaps cannot again because of the route… though wonder that router limitation was about vaults and not the CLIs.
Nevermind… 5mins ![]()
After checking countless times I finally surrendered to the idea that I screwed up. Came to turn the pi off and continue my life.
I have CHUNKS!!!.. damn what an agonizing few hours. Feel I need a beer.
I think the system is optimised to delay handing out chunks til the last minute…
I believe I can shine some light on the situation of chunks being delayed. ![]()
When a Vault starts, it initializes itself as an Adult and approaches routing to make it part of a section. When routing does so, the node is added as an Infant. Infants are not given chunks.
Eventually the node is promoted to an Adult and only after that it will be given chunks to be stored. It will not store already existing chunks but only new ones that come in, provided it is one of the 3 adults that is closest to the data address.
To be more specific about the node being promoted to an Adult, it happens on churn. For example, when I start a node it will join as an Infant. When another node joins the network, my vault will be promoted to an Adult.
This (as blatantly obvious as it should have been to start) finally worked itself out in my head after.
I think part of the stress about not receiving chunks or any activity in the log for hours was thinking I did something wrong. Thinking that I did something wrong cancels/supersedes rational thought in my case.
And how do we preserve old data? If this process is maintained, as older Vaults are replaced fewer and fewer nodes will store this old data.
We will duplicate all chunks from any node that leaves. This is a part we want to play around with, i.e. relocate chunks on every churn (including join) or only on leave and so on.
Thanks for this effort @tfa. I will try and setup my pi this weekend. Do you or anyone knows if you can connect through vpn, if I remember correct @Zoki tried connecting through vpn on earlier tests.
Current network status:
- 1 adult (yesterday there were 4 adults)
- between 375 and 1040 MB virtual size used in a vault
- 178 MB max disk space used in a vault
- 6 users with a safe key
- 2007 coin units spent by users (a unit is 10E-9 safecoins, in other words the equivalent of satoshis for Bitcoin)
We had a power cut overnight and I have not yet got around to starting a vault again. I will do so now
hmm failing here with
willie@gagarin:~/projects/maidsafe/VfH-tfa$ ./safe_vault -h’[“95.217.214.231:5483”]’ -vv > VfH-vault.log
INFO 2020-06-18T23:01:48.053554226+01:00 [src/bin/safe_vault.rs:94] Auto updates are disabled
INFO 2020-06-18T23:01:48.053607408+01:00 [src/bin/safe_vault.rs:120]
Running safe-vault v0.24.0
==========================
INFO 2020-06-18T23:01:48.065542128+01:00 [/cargo/git/checkouts/quic-p2p-2ed24583cc4479e8/1f47bb8/src/igd.rs:118] Fetched IP address from IGD gateway: V4(192.168.100.203)
INFO 2020-06-18T23:01:48.065904678+01:00 [/cargo/git/checkouts/routing-c03a5020310cb7a2/c7b8c67/src/node/mod.rs:129] 8d3f55.. Bootstrapping a new node.
ERROR 2020-06-18T23:01:48.072411690+01:00 [src/utils.rs:37] Failed to load /home/willie/.local/share/safe_vault/root_dir/holder_data.db: No such file or directory (os error 2)
If you have already launched a vault on this PC in the past, then try to delete ~/.local/share/safe_vault/root_dir/ directory before launching a new one.
Edit: or if another vault is currently running on this PC, then use -r option to define a different root dir.
Thats looking more like it now - thanks
I am back too,
It should be up for a while now!
How fast testnet is?
Network is dead now. At around 08:17 GMT, 5 elders crashed on a memory allocation:
135.181.26.49 : memory allocation of 11534336 bytes failed
95.217.214.96 : memory allocation of 1501806 bytes failed
95.217.214.150: memory allocation of 11534336 bytes failed
95.217.214.231: memory allocation of 23068672 bytes failed
95.217.215.17 : memory allocation of 11534336 bytes failed
Which is probably the same error that happened to last week Maidsafe IGD test net.
I suppose this network lasted longer simply because it had less users and so it took more time to get to the failure point.
Anyway it was an interesting experiment. Thanks to every one that participated.
I found it was very fast, both in uploads and downloads.
I ended up with 572 files in chunks/immutable totalling 44 MB. Pretty cool to be part of the experiment thanks for setting it up @tfa