Having them all on the same port might be the cause of the trouble then… tweak tcp_acceptor_port for each and then it might be clearer if that is the only difference needed.
It has always worked in the past, since the port on the client vaults is actually determined by crust. It is the hard-coded contacts that need pre-determined ports for the sake of going in the config.
The fact that three are connected, with tables of 19,17 and 15, tends to support that.
You might be right but it was only that difference to tcp_acceptor_port that allowed mine to not fall over initially.
OK, but it was only when I changed the tcp_acceptor from null to something that it started working. 
If I understand it correctly, a vault will exit if it can’t find another vault.
Mine wasn’t null initially… just all set as 5483… stands to reason that if they are all listening to the same port, they will get confused.
Four out of the five are now connected (all on one host!) with tables 17-19. One still saying it will take a while.
Launcher won’t let me create an account.
It was null in the release config for testnet4. I changed it to 5483 in what I posted for everyone to use, since i found that it worked with something and not with null, and 5483 seemed a good choice.
If first part of the config lists the ports that hard-coded contacts are listening on then obviously the second part has to tell this vault to listent on that port if it is also a hard-coded contact listed in the first part.
Thanks for making that point… yes. Still, that only need be and perhaps should be one vault… and if you’re host to a seed then perhaps that should be the --first one. Accepting messages via a shared port though I would expect could not work in a reliable way for as soon as the vaults experience diverges, the messages they hear will become at odds with what they are wanting or expecting.
Launcher created an account, but demo app never gets authenticated, and launcher’s console is like this:
$ ./safe_launcher
INFO 23:12:28.234323996 [routing::core core.rs:1171] Bootstrapping(PeerId(ad5c…), 0)(c22042…) Connection failed: Proxy node needs a larger routing table to accept clients.
INFO 23:12:38.914490876 [routing::core core.rs:1171] Bootstrapping(PeerId(ad5c…), 0)(15f79f…) Connection failed: Proxy node needs a larger routing table to accept clients.
The seed, --first, is by itself on a dedicated server in the cloud. The local, client vaults are on a host here with me on my LAN. There should be no conflict, and I don’t see any. All five local vaults now have tables.
Only your and my hard-coded contacts are online, the other one is offline, so anything connecting, by random choice gets stuck on the offline one until it trips over to one of the others.
I only got that when I forgot to update the launcher config file. Would have expected on your end though that if would look to your seed that is suggested and through that the to the rest of the network table.
My demo app is getting there (“taste of things to come”), just taking a while because the same, local host is doing the nightly build and upload of packages.
Very good…
I’ll leave it running now, as a challenge for others to see if they can stress what is there to breaking point.
I expect many calls to http://odyssey.safenet would do it as that’s a ~2Mb file.
1 Like
Thanks but I’m wrestling with networking and firewalls for a whole wannabe datacenter
And everyone I ask for advice contradicts the last one…
so MaidSafe is not high on my priorities right now - maybe tomorrow
I finally got there: http://test.bluebird.safenet/
I saw some interesting errors in the launcher console (in the current session while successfully creating the site above):
$ ./safe_launcher
INFO 23:43:47.196414250 [routing::core core.rs:1171] Bootstrapping(PeerId(5846..), 0)(91de49..) Connection failed: Proxy node needs a larger routing table to accept clients.
INFO 23:44:19.888752080 [routing::core core.rs:1171] Bootstrapping(PeerId(2814..), 0)(d999ce..) Connection failed: Proxy node needs a larger routing table to accept clients.
ERROR 23:55:25.665233925 [safe_core::ffi mod.rs:302]
--------------------------------------------------
| FfiError::DnsError -> DnsError::DnsNameAlreadyRegistered
--------------------------------------------------
ERROR 00:03:17.257001324 [safe_core::ffi mod.rs:330]
--------------------------------------------------
| FfiError::InvalidPath
--------------------------------------------------
ERROR 00:03:18.075699016 [safe_core::ffi mod.rs:330]
--------------------------------------------------
| FfiError::InvalidPath
--------------------------------------------------
I’m wondering what proxy node it is referring to that doesn’t have a large enough routing table. I had pruned my local vaults to two to speed things up, and they have 15 and 16 entries. And the DnsNameAlreadyRegistered error makes me wonder how the website creation did succeed anyway.
Also, why am I able to start 2-5 vaults on my LAN on a build (“latest”) that includes the restriction to one vault per LAN? Hmm…
Thanks for starting down that road. It will be a welcome addition.
1 Like
Hmm, the seed vault had a zero-sized Node.log, so I stopped it and restarted it without the -f flag, since there was an active network already up, and it immediately got a routing table of 17 or so. I’ll leave it like that.
So does it work now? And if so where do I get the proper configs?
It has worked all along. It’s called “an experiment.”
Thanks for the reminder, though! I have just updated the configs at http://91.121.173.204/configs/
I’ll update the packages right now (ten minutes).
EDIT: The packages also are now updated.
2 Likes