I’m going to restart all my vaults and the host in the next minute.
Very nice @bluebird
Does anyone know if this kind of config would work for a local network (e.g. substituting 127.0.0.1 and running eight vaults)?
That would also be a useful option for testing apps against SAFE Launcher for me - no need to worry about status of internet or external network.
Uploaded my site, which has seen a couple of improvents as I try to learn some HTML/CSS stuff. Gotta start somewhere I guess
Also tried my hand at some basic javascript:
@aenemic What does your safe_launcher.crust.config look like?
{
“hard_coded_contacts”: [
{
“tcp_acceptors”: [
“91.121.173.204:5483”,
“207.172.241.242:5483”
],
“tcp_mapper_servers”:
}
],
“tcp_acceptor_port”: 5483,
“service_discovery_port”: null,
“bootstrap_cache_name”: null,
“tcp_mapper_servers”:
}
the same as my vault one
Thank you. Playing with it now.
By the way, @happybeing , using 127.0.0.1 gives “connection refused”. However, multiple docker instances might work, each with a different LAN IP.
Thanks - maybe mock-routing is the way to go for that. I’d forgotten about that option!
Actually, I was overly hasty in saying that. It appears that the 127.0.0.1 refused was not the result of my putting it in but it is crust trying wildly to connect to anything and everything.
Something else very interesting that I just noticed while going through the errors generated by a local vault:
I see many errors like this:
“Connecting to endpoint 91.121.173.204:39400 failed: Cannot assign requested address”
The IP is my dedicated server but the port is not one that I have ever used and is nowhere in my configs. Similar messages appear with these ports:
59945, 48580, 42883, 54958, 37762, 34140, 50170, 50171, 61579, 53068
None of which I’m using.
What’s up with that? It is probably crust again, trying various things, but why those particular ports, as if it were expecting something to be listening on them? The only explanation I can think of is that it is a small set of ports Maidsafe has open on their droplets. I ran grep on all their source code and couldn’t find them there. There is no other reason to try a handful of random ports. Even a port scan tries to scan the entire space quickly and that isn’t what is going on here, since each attempt is patiently repeated on a handful of IPs over many minutes.
Nat traversal → We do a lot of try mapping ports, connect A to C to give a port to B and vice versa. IT’s a lot of canoodling about. What you are seeing is a decentralised STUN server basically. It will try and use upnp, STUN like capabilities, direct connection etc. to get through. This part has been very successful and will get even better.
If your Vault is running for longer than 2 hours, please restart. Otherwise we’ll be on separate networks.
The network after the restart by @bluebird is about 14 nodes/vaults right now:
Also be aware these were test vaults, so the traffic is immense. There are a significant set of changes in the pieline that we hope to release another test very soon. The next test will make a community testnet much simpler. Large churn will lose data in a small testnet like this just now - so beware
We are flat out in house, but watching every so often and I will help when I Can, but the key is forward progress for us, so we are limited a bit. Try and not switch off too many vaults at once, perhaps a small delay between them as you do.
FYI In normal Kademlia networks under 2500 nodes the results or all over the place, now I think we are more efficient by a large margin, but 20-> few hundred vaults is a tiny network with a lot of imbalance. So just setting expectations here It’s great to see though
Edit also copy all exe configs to new directories for every vault you run like this and you can tail -f Node.log
to get more detailed info. If you run a few in same dir they will overwrite each others logs - perhaps
Completely understandable that you should not devote any resources to this. Its fun to have it up to play with though, and I must say I think it runs remarkably well for such a small network atm. Very low CPU use, traffic very managable. Loads fairly quickly.
Have had 4 vaults running for a couple of hours without problems.
Only makes me that much more excited to see the coming tests
That’s good information. I’ll stagger the restarts. From what you say, a couple of dozen vaults, particularly test versions, would be unstable and prone to lockouts and slowdowns.
Even though I’m using the same config as @aenemic , I’m not getting my launcher to authenticate nor to process new registrations. This is with a vault on the same host and with a config that includes the LAN IP of the host. The console for the launcher keeps saying there is no IGD gateway on the network interface.
If it does STUN functionality as you say then it should not matter whether I redirect ports in the router or not, so I’ll leave that alone and concentrate on other aspects.
I am seeing a lot of messages like this:
INFO 13:55:13.114258586 [routing::core core.rs:1768] Sending GetNetworkName request with: PublicId(name: 0430…). This can take a while.
ERROR 13:55:43.114118577 [routing::core core.rs:2187] Failed to get GetNetworkName response.
WARN 13:55:43.114318237 [safe_vault::vault vault.rs:134] Received Event::GetNetworkNameFailed. Restarting Vault
What is this “network name”? I thought that was something coming in the next version.
strange, I had some trouble with getting “connected to safe network” but when i restarted vault as well, it worked again.
You can’t create your own address on SAFE, the network provides you one. So I think it’s going from IP to XOR. You are on IP-level sending out a request to a group to pick you up and provide you with an address. After they do they’ll relocate you to another group with your close nodes. That’s how I understand it. Can’t say with 100% certainty.
It may be related to the message, early on in this experiment, where one isolated vault would listen for 20 minutes and then announce that it was the seed of a new network.
Which would explain why things went well early on, when I could connect the launcher (although not run the demo apps). Now i see many more (it seems) messages like this network name error, and no functionality in the launcher. Also, consider @dirvine 's comment that there is a danger separate networks forming.
The test net might be having an identity crisis.
Indeed, what if you were to add my ip to your launcher/vault conf?
The one you gave me is in my launcher and vault configs on one, local host. My server in the cloud is running the same configs as as yesterday and does not have your IP.