Thank you both (and anyone else) very much for participating. Right now I’m going to sleep but I shall return to this in the morning.
1 Like
OK, I made a mistake in using the config as supplied in Maidsafe’s release, substituting only the IPs of the hard-coded contacts. In fact, you need to have the tcp_acceptor_port set to an actual port and not “null”. Duh!
I have now uploaded corrected configs, although it probably makes no difference to the launcher.
It does appear that, in the 0.9.0 release binary, there is a hard-coded limit of two for the number of vaults on a LAN. At least, that’s what I consistently find when only one hard-coded contact is accessible.
So there is one hard-coded contact running and two local vaults of mine connected right now. All three are running the official “release” binary rather than my unofficial “latest” binary, in order to have a known baseline. Once we have a quorum for launcher connections then we can consider experimenting with the latest binary.
Let’s add more vaults!
I have taken the liberty of putting together packages for the four options, with everything already assembled in a folder. I hope Maidsafe don’t mind and if they object then I’ll take the packages down immediately and without complaint. My reasons for doing this are:
-
Convenience for the members. We might get a few more as a result.
-
When someone has a problem, it is easier to help if I know exactly what is being run.
The packages are linked below, and I’ll add them to the OP. Please download one, probably “community1-amd64-release” if your computer is a regular PC running 64-bit Linux, and run one or two instances of it (i.e., separate folders). No modifications or additions are required!
Packages: http://91.121.173.204/packages/
3 Likes
INFO 02:13:09.925714910 [safe_vault safe_vault.rs:96]
Running safe_vault v0.9.0
=========================
DEBUG 02:13:09.927852718 [crust::main::service service.rs:552] Network name: Some("community1")
DEBUG 02:13:12.679280349 [crust::main::active_connection active_connection.rs:57] Entered state ActiveConnection: PeerId(4fc2..) -> PeerId(0ab7..)
DEBUG 02:13:12.679439897 [routing::core core.rs:550] Disconnected(5ce90b..) Received BootstrapConnect from PeerId(0ab7..).
DEBUG 02:13:12.679488303 [routing::core core.rs:1063] Disconnected(5ce90b..) - Sending ClientIdentify to PeerId(0ab7..).
DEBUG 02:13:12.956161606 [routing::core core.rs:1276] Client(5ce90b..) - State changed to client, quorum size: 2.
INFO 02:13:12.956274719 [routing::core core.rs:1032] Client(5ce90b..) Running listener.
INFO 02:13:13.644857211 [routing::core core.rs:1555] Client(5ce90b..) Sending GetNodeName request with: PublicId(name: 5ce90b..). This can take a while.
INFO 02:14:13.644692709 [routing::core core.rs:1807] Client(5ce90b..) Failed to get GetNodeName response.
WARN 02:14:13.644834422 [safe_vault::vault vault.rs:171] Restarting Vault
DEBUG 02:14:13.645838746 [crust::main::service service.rs:552] Network name: Some("community1")
DEBUG 02:14:16.298550351 [crust::main::active_connection active_connection.rs:57] Entered state ActiveConnection: PeerId(2e52..) -> PeerId(0ab7..)
DEBUG 02:14:16.298749077 [routing::core core.rs:550] Disconnected(7ac13b..) Received BootstrapConnect from PeerId(0ab7..).
DEBUG 02:14:16.298765457 [routing::core core.rs:1063] Disconnected(7ac13b..) - Sending ClientIdentify to PeerId(0ab7..).
DEBUG 02:14:16.575615188 [routing::core core.rs:1276] Client(7ac13b..) - State changed to client, quorum size: 2.
INFO 02:14:16.575692370 [routing::core core.rs:1032] Client(7ac13b..) Running listener.
INFO 02:14:17.244908561 [routing::core core.rs:1555] Client(7ac13b..) Sending GetNodeName request with: PublicId(name: 7ac13b..). This can take a while.
/me applauds @bluebird for heroic testing efforts!
2 Likes
6f5486…
01c4aa…
5ce90b…
7ac13b…
84154f…
75ce31…
e1f268…
91c436…
a9d3b7…
b2b2e4…
49065a…
c2b7a1…
b8a876…
ffa72b…
e9dfa3…
911d8d…
-
Pretty sure this qualifies as a resounding success!
-
Not going to keep streaming out this update, but AM adding six *pi nodes…
-
Are the two version supposed to be compatible with one another?
-
More generally, how does maidsafe handle version updates while keeping the network consistent/coherent?
-
Wow, so yeah, the size of this network confirms the theory that for everyone who posts on this forum, there are another 10 who lurk.
I can’t find any of those IDs amongst mine.
I don’t know about their compatibility; that’s something to find out. My two connected nodes, as well as the seed node, are running “release”. Two more local nodes that I added with “release” were cycling with that “it can’t take a while” message. So I changed them to “latest” and they are still cycling with that message. 
2 Likes
I’m running latest. Just for the hell of it, going to shutdown and restart my node. Haven’t added pis yet.
Shut down, restarted:
1407f0…
057b4e…
371c00…
adb9ad…
34decc…
b48079…
9c889c…
69d2b3…
fcb154…
no joy here … 
willie@leonov:~/projects/maidsafe/community/community1-amd64-latest$ ./safe_vault
INFO 00:23:47.180216916 [safe_vault safe_vault.rs:96]
Running safe_vault v0.9.0
INFO 00:23:49.387045266 [routing::core core.rs:1171] Bootstrapping(PeerId(f7ff…), 0)(4b4b29…) Connection failed: Proxy node needs a larger routing table to accept clients.
INFO 00:23:50.586684113 [routing::core core.rs:1171] Bootstrapping(PeerId(1b9f…), 1)(4b4b29…) Connection failed: Proxy node needs a larger routing table to accept clients.
INFO 00:23:51.996535139 [routing::core core.rs:1032] Client(4b4b29…) Running listener.
INFO 00:23:55.084388387 [routing::core core.rs:1555] Client(4b4b29…) Sending GetNodeName request with: PublicId(name: 4b4b29…). This can take a while.
INFO 00:24:55.084203006 [routing::core core.rs:1807] Client(4b4b29…) Failed to get GetNodeName response.
WARN 00:24:55.084370242 [safe_vault::vault vault.rs:171] Restarting Vault
INFO 00:24:57.291600415 [routing::core core.rs:1171] Bootstrapping(PeerId(0ee9…), 0)(372648…) Connection failed: Proxy node needs a larger routing table to accept clients.
INFO 00:24:58.491886391 [routing::core core.rs:1171] Bootstrapping(PeerId(7eba…), 1)(372648…) Connection failed: Proxy node needs a larger routing table to accept clients.
INFO 00:24:59.818863876 [routing::core core.rs:1032] Client(372648…) Running listener.
INFO 00:25:02.889279672 [routing::core core.rs:1555] Client(372648…) Sending GetNodeName request with: PublicId(name: 372648…). This can take a while.
I can’t explain it really. My two local vaults connect to the one hard-coded contact (Rupert’s out of reach, and his vault is inaccessible) but no other of my local vaults will connect. And other members, such as you, report that they can’t connect (can’t get node name, etc). And I’ve covered all bases as far as making sure everyone is on the same page, configuration-wise.
I would have expected that if my two nodes can connect then other people, running the same package, would be able to connect a couple of nodes.
The conclusion therefore is that the seed vault will only accept two vaults TOTAL. By the way, I get the same result whether I use “release” or “latest” on the seed vault. They seem interchangeable on both server and locally.
Without more hard-coded contacts, I can’t determine if that is due to a lack of bootstrap vaults.
It probably isn’t helped by the fact that service discovery and caching are turned off. For example, the vaults don’t do the furious crust-ing, trying every port they can, that we saw with earlier official testnets.
3 Likes
Thanks for all your hard work anyway. We’ll get there , I know it
5 Likes
Here’s the thing: Over the next week they will be incorporating the results of Testnet4 and re-enabling caching. There could also be a Testnet5. So the pace of development is fairly rapid. My packing system will enable a quick deployment next time around. Indeed, I shall keep the seed vault up and my local nodes (all two of them) and perhaps the other hard-coded contact will shortly be back in operation. And the latest binaries will be up, as soon as new versions of the code are posted on the repo, for people to grab and jump onto this network.
5 Likes
Using the latest binaries… and packing those up yourself… does that not add a complication?
Would it not be easier just to run with the original that each test puts forward?.. and also more people might be inclined to trust those that Maidsafe puts forward rather than necessarily trusting community ones??
I don’t understand how latest binaries would be expected to run smoothly, if they are not new releases that a all consistent with other parts… and surely that only happens at each test release that Maidsafe is doing?
Have you tried running the communityvT4 with the Test4 binaries and just tweak the config for seed IPs??
From what I saw of last posts it seems the improvements in the works will see the community simply continue from where the droplets fall away, rather than an entirely new network reboot being needed… to be expected that will make it easier all round… and that would encourage that everyone is using the same binaries. Have bleeding edge perhaps will complicate the picture of what issues there really are?
Thanks again for trying this round… I didn’t get a connection from new or Test4 binaries, so perhaps missed when the seed were active.
Yes.
There is not a lot of functional difference between latest and release, right now.
“Release” is somewhat crippled, as we saw with testnet4 and community1. “Latest” is bound to soon get better as they re-enable caching and service discovery.
It is not complicated for me: Scripts automatically do the packaging and upload between 11pm and midnight BST.
Did you try adding a vault?
EDIT: Also, as far as tweaking goes: I control only one hard-coded contact. the other is inaccessible at present. If anyone would like to volunteer an IP to add to the configs, it would be most welcome. And if you have a specific tweak in mind then please describe it.
As suggested above, I didn’t get a connection from new or Test4 binaries, so perhaps missed when the seed were active.
1 Like
To test whether there is a hard limit of two client vaults per bootstrap node, I have taken my two client vaults down. Could someone please restart their vaults and see if they connect?
Appears to immediately drop back to commandline without comment… previously it maintained “This can take a while.”
I have just now restarted it. Try it now. (running “latest”)
10 “This may take a while.”
20 “Restarting”
30 goto 10
I take if you’ve got port fowarding set up and no firewall … at least on that port?
… or is this what it does necessarily if there are not enough nodes??..
Given that the launcher suggests
Connection failed: Proxy node needs a larger routing table to accept clients.
I expect perhaps we need to just see a few more nodes before the network considers that it’s alive. I can’t be sure I know how many that is now but expect that more the merrier,. perhaps it’s 16 or 32 or 64…
I recommend to leave the launcher until we have seven vaults up.
The hard-coded contact 91.121.173.204:5483 has the port open on 5483. It is directly connected (non-NAT).
The hard-coded contact 185.16.37.156 is not accessible.
I see exactly two vaults in its routing table (neither of them mine):
INFO 12:31:01.199112230 [routing::core core.rs:1371] Node(d3ab25..) Added 5abc1d.. to routing table.
INFO 12:31:01.201512674 [routing::core core.rs:411] ---------------------------------------------------------
INFO 12:31:01.201700037 [routing::core core.rs:413] | Node(d3ab25..) PeerId(4ca3..) - Routing Table size: 1 |
INFO 12:31:01.201850559 [routing::core core.rs:414] ---------------------------------------------------------
DEBUG 12:31:01.208966567 [safe_vault::vault vault.rs:302] Vault connected
DEBUG 12:32:53.407309630 [crust::main::active_connection active_connection.rs:57] Entered state ActiveConnection: PeerId(4ca3..) -> PeerId(7c61..)
DEBUG 12:32:53.442448503 [routing::core core.rs:1328] Node(d3ab25..) Accepted client 6fc154...
DEBUG 12:32:56.765303423 [routing::core core.rs:1640] Node(d3ab25..) Responding to client Client { client_name: 6fc154.., proxy_node_name: d3ab25.., peer_id: PeerId(7c61..) }: GetNodeNameResponse { [PublicId(name: d3ab25..), PublicId(name: 5abc1d..)], PublicId(name: 95e49f..), MessageId(25abf7..) }.
DEBUG 12:32:56.818639034 [routing::core core.rs:1339] Node(d3ab25..) Handling NodeIdentify from 95e49f...
INFO 12:32:56.818948090 [routing::core core.rs:1371] Node(d3ab25..) Added 95e49f.. to routing table.
INFO 12:32:56.819169360 [routing::core core.rs:411] ---------------------------------------------------------
INFO 12:32:56.819310381 [routing::core core.rs:413] | Node(d3ab25..) PeerId(4ca3..) - Routing Table size: 2 |
INFO 12:32:56.819442545 [routing::core core.rs:414] ---------------------------------------------------------
EDIT: If I now start a local vault I get the “it can take a while” message. I think that proves that the bootstrap vault will only accept two client vaults total. There was nothing different about my local setup compared to anyone else. I just happened to run my local vaults straight after bringing the bootstrap vault up, so they were the first in.
EDIT1: Now this is where it gets interesting, because I know just enough Rust to look in the code and find where the limit of two is applied. 
After I have a bite to eat I’ll see if I can put up a “jailbreak” version to go along with “latest” and “release”.
2 Likes
Hmm, I’m a bit out of my depth in parsing the code. I did find this but I’m not sure sure what a token is so no way to proceed:
To further prove the point that a safe_vault bootstraaping vault stops listening after accepting a couple of client vaults:
The telnet command is a way to tell if something is listening on that port. If you get a response similar to below then it means it is accessible:
$ telnet 91.121.173.204 62000
Trying 91.121.173.204...
Connected to 91.121.173.204.
Escape character is '^]'.
That was after I changed my config just now to port 62000. A few minutes ago, when it was on 5483, it was giving the response “connection refused.”. Both ports are open in my firewall, but safe_vault stops listening once it has accepted a couple of client vaults.
I’ll put it back on 5483 now that I’ve proven the point.
So the above tests prove that it is safe_vault stopping listening for TCP connections (both release version and latest version) that is the issue. I believe that is set in the crust code I cite above, but I don’t have the coding skills to tweak it.