Local Test Network


#1

Does anyone know the current best way to set up a local test network? Being limited to 500 PUTS seems like it will get in the way of prototyping pretty quickly. I know that the core MaidSafe team has plenty of experience deploying these test networks, so I’m wondering if there is a write up of how to deploy one (or a script to automate the process).

Thanks!


#2

Well if you have a bunch of machines on LAN, you wouldn’t even need a config file i suppose - they should all discover each other and form a local network. Then you could run a client and that would basically bootstrap to the vault that first responds to it and you will have your local test net up and running with clients. (I cannot assert i am totally not stale on this though - e.g. one vault per LAN restrictions etc. , but do ping if you have problems).


#3

It’s great to know that it is possible on a LAN. I’m afraid I don’t feel like I totally understand what we would need to run to start the self discovery process. What is the config file that I don’t need (even though I don’t need it I bet understanding it would help me)? Would just running a bunch of instances of the safe_launcher do the trick? Do we need to do things with vaults?

Thanks!


#4

Yes vaults are the network (where storage etc. happens). If you compile safe_core with mock routing then use that to compile the launcher you have a self_contained network (mock). The launcher readme should show the steps, it would be great to know if any are missing for you. https://github.com/maidsafe/safe_launcher

Thanks for being involved :thumbsup:


#5

config files are crust config files - they contain among other things, a list of endpoints that crust can potentially bootstrap to. Running bunch of luanchers will only give you a bunch of clients. You will need vaults (entities that store data, manage redundancy etc) to do anything useful. So will need to run a few (say 10) instances of vaults and then perhaps a client (Launcher). If you just want to wire up something to test and don’t care about what goes on in the background (it’s transparent to apps anyway), then you could just use a Launcher that integrates with safe_core built against mock-routing. That makes safe_core totally mock basic functionality of vaults and routing (without any actual networking involved in the background) to give an illusion that it is talking to a valid network. To build safe_core with mock following the instructions here. Similarly head to safe_launcher repo and follow the instructions there to finally get launcher up and running.


#6

This looks great! Thanks!


#7

I run a local network for testing, and there are a few limits that I remove from vaults (I haven’t used mock routing, which may be adequate for your needs).

After these changes, the new vault binary will need to be built from source.

That’s it for vaults, but then the demo app has upload limits that need to be changed if you’re using it to test.

This is quite a lot of work to get up and running, so I made a script called SafeInABox which does all this work. I confess these days I usually use it simply as a reference for where and what to change, and it probably won’t suit your needs as-is, but it’s worth a look.

Hope this helps, I’ve done a lot of work in this area (see Profiling Vault Performance) so am happy to answer any questions.


#8

Thats fantastic. Exactly what I was looking for.


#9

Thanks @mav, I think I will have to try this out soon so hopefully it is still up to date. I am writing my own Rust client for the SAFE Network to learn the API better so I think I will soon need a test network for that as I am already almost at my PUTs limit. (Not to mention I would like to write Elm, Javascript and Ruby versions too at some point as well.)

So just FYI team I may be back with question about using a test network soon. :slight_smile:


#10

Yay for Elm! I hope to see an Elm package for the API eventually.


#11

There are some additional things that recently required changing as outlined by @tfa in


#12

For future records, a full list of modifications required to run a local network on Test 12C (ie vaults 0.13.1)

Test 12C

The diffs below are git diffs - any line starting with a minus sign is to be removed, any line starting with a plus sign is to be added.

language versions

$ rustc --version
rustc 1.16.0 (30cf806ef 2017-03-10)
$ cargo --version
cargo-0.17.0-nightly (f9e5481 2017-03-03)
$ node --version
v6.0.0
$ npm --version
3.8.6

safe_vault

git checkout 0.13.1

src/bin/safe_vault.rs
remove linting for unused and warnings

L27
-          unknown_crate_types, warnings)]
+          unknown_crate_types)]

L33
-        unknown_lints, unsafe_code, unused, unused_allocation, unused_attributes,
+        unknown_lints, unsafe_code, unused_allocation, unused_attributes,

src/lib.rs
remove linting for unused and warnings

L201
-          unknown_crate_types, warnings)]
+          unknown_crate_types)]

L205
-        unknown_lints, unsafe_code, unused, unused_allocation, unused_attributes,
+        unknown_lints, unsafe_code, unused_allocation, unused_attributes,

Cargo.toml
use local copy of routing

L24
-routing = "~0.28.2"
+routing = { path = "/home/user/maidsafe/routing" }

src/personas/maid_manager.rs
remove account limits

L34
-const DEFAULT_ACCOUNT_SIZE: u64 = 500;
+const DEFAULT_ACCOUNT_SIZE: u64 = 500000000;

routing

git checkout 0.28.2

Cargo.toml
use local copy of crust

L13
-crust = "~0.22.0"
+crust = { path = "/home/user/maidsafe/crust" }

src/states/node.rs
Remove proof of work check for peers on local network

L1326
         let (difficulty, target_size) = if self.crust_service.is_peer_hard_coded(&peer_id) ||
+                                           self.crust_service.has_peers_on_lan() ||
                                            self.peer_mgr.get_joining_node(&peer_id).is_some() {
             (0, 1)
         } else {

Do not disconnect based on whitelist (@tfa this hasn’t been mentioned anywhere else yet, and was the missing piece of the puzzle for me to reliably bootstrap my pine64 network)

L398-406
-         if !self.crust_service.is_peer_whitelisted(&peer_id) {
+         if !self.crust_service.is_peer_whitelisted(&peer_id) && false {
             debug!("{:?} Received ConnectSuccess, but {:?} is not whitelisted.",
L1261
-         if !client_restriction && !self.crust_service.is_peer_whitelisted(&peer_id) {
+         if !client_restriction && !self.crust_service.is_peer_whitelisted(&peer_id) && false {
             warn!("{:?} Client is not whitelisted, so dropping connection.",

src/states/bootstrapping.rs
Fix FailedExternalReachability

L67
-                let _ = self.crust_service.start_bootstrap(HashSet::new(), CrustUser::Node);
+                let _ = self.crust_service.start_bootstrap(HashSet::new(), CrustUser::Client);

L133
-            let crust_user = if self.client_restriction {
-                CrustUser::Client
-            } else {
-                CrustUser::Node
-            };
             let _ = self.crust_service
-                .start_bootstrap(self.bootstrap_blacklist.clone(), crust_user);
+                .start_bootstrap(self.bootstrap_blacklist.clone(), CrustUser::Client);

src/node.rs
Allow peers on lan

L116
-                              self.deny_other_local_nodes && crust_service.has_peers_on_lan() {
+                              self.deny_other_local_nodes && crust_service.has_peers_on_lan() && false {

crust

In theory this shouldn’t need to be local since there are no modifications, but I found it wouldn’t work without using the local copy.

git checkout 0.22.0

src/lib.rs
remove linting for warnings and deprecated

L29-L30
-          unknown_crate_types, warnings)]
-#![deny(deprecated, improper_ctypes, missing_docs,
+          unknown_crate_types)]
+#![deny(improper_ctypes, missing_docs,

safe_client_libs

Required for safe_launcher

git checkout 0.22.3

Cargo.toml
use local copy of routing

L21
-routing = "~0.28.2"
+routing = { path = "/home/user/maidsafe/routing" }

src/lib.rs
remove linting for warnings and unused

L29
-          unknown_crate_types, warnings)]
+          unknown_crate_types)]

L33
-        unknown_lints, unsafe_code, unused, unused_allocation, unused_attributes,
+        unknown_lints, unsafe_code, unused_allocation, unused_attributes,

safe_launcher

git checkout 0.10.2

No code modifications required.
Copy the custom binary libsafe_core generated from safe_client_libs to app/ffi/

demo_app

demo app is v0.6.2 which is in git tag 0.10.1 of safe_examples repo

git checkout 0.10.1

demo_app/config/env_[production|test|development]
Remove upload limits on filesize

L3-L4
-  "isFileUploadSizeRestricted": true,
-  "maxFileUploadSize": 25000000
+  "isFileUploadSizeRestricted": false,
+  "maxFileUploadSize": 25000000000000

#13

Again, I have problems to run a local network.

It was Ok until commit ba64cf9 (included) of routing. I implemented principles defined above in my fork here.

But I tried to reimplement them on latest commit (ec585d1) but that doesn’t work anymore.

First, I came across this error:

INFO 23:21:20.552017000 [routing::states::bootstrapping bootstrapping.rs:295] Bootstrapping(506a15..) Connection failed: Proxy node needs a larger routing table to accept clients.

The workaround I found was to add the line testing the local-network feature in src/states/node.rs:

         if (peer_kind == CrustUser::Client || !self.is_first_node) &&
            !cfg!(feature = "local-network") &&
            self.routing_table().len() < self.min_section_size() - 1 {
             debug!("{:?} Client {:?} rejected: Routing table has {} entries. {} required.",
                    self,

But then the nodes fail to get relocated name:

INFO 22:58:05.075736900 [safe_vault::vault vault.rs:96] Use local-network feature
INFO 22:58:10.875088900 [routing::states::joining_node joining_node.rs:294] JoiningNode(f030ab..()) Requesting a relocated name from the network. This can take a while.
INFO 23:04:10.893171200 [routing::states::joining_node joining_node.rs:317] JoiningNode(f030ab..()) Failed to get relocated name from the network, so restarting.
WARN 23:04:10.893675800 [safe_vault::vault vault.rs:143] Restarting Vault
…

I suppose this is because the node connects as a client. But this was the way to make local network works until now. Without it I get the following error:

ERROR 23:39:38.478785200 [crust::main::bootstrap mod.rs:188] Failed to Bootstrap<UID>: (FailedExternalReachability) Bootstrappee node could not establish connection to us.

So now I am blocked. Please, could Maidsafe give some indications on making the local network works.

Note: I am pretty sure there was another thread about local networks where we were discussing the possibility to add a feature gated local network. I remember that this idea was postponed but the problem is that I don’t find this thread anymore.

Edit: I have found the thread. It is not a public topic but a PM in the other forum (initiated by @viv to @mav and me).


#14

I still fail in running a local network. I tried some modifications but none succeeded.

Could @maidsafe indicates how to modify the code to make it work?


#15

I found a way for local networks. There are modifications in 3 crates. They are available in my forks on GitHub:

To anyone: To create a local network, just clone the last one (safe_vault) and build safe_vault binary with cargo build --features "local-network" command.

@maidsafe: I didn’t make PR’s because there are probably things you wouldn’t code like I did, but please, take local networks into account in your base code. It is a pain to find how to do it each time there is a major change.


#16

Thanks @tfa, this is awesome! Could you please share your vault / crust config files? I’m able to build your version of the vault but then it just shuts down after a while. Did you run all instances locally on one machine?


#17

I don’t have any config files and I run all vaults locally on one machine.

I launch seed node with RUST_LOG=info ./target/debug/safe_vault -f in a first command window and then each following nodes with ./target/debug/safe_vault& in another command window.


Local Test Network #2
#18

My previous forks were not compatible with test17 client binaries. I tried to modify them but I didn’t succeed in making them work.

So, instead, I have recreated them from current master branches in hope that local networks created with new safe_vault will be compatible with next client binaries.

I am looking forward these binaries to test this possibility.


#19

I had to add a small modification in routing to inhibit control of number of clients, but now local network work with new client binaries delivered by Maidsafe (with rate limiter). I just did a little test: created an account, added a service with a one file site and browsed to it successfully.

The procedure to create a local network is the following:

  • git clone https://github.com/Thierry61/safe_vault.git
  • cd safe_vault
  • cargo build --features “local-network”
  • launch the seed node in a first command window: RUST_LOG=info ./target/debug/safe_vault -f
  • launch other nodes in another command window: ./target/debug/safe_vault&. Do it at least 7 times and wait 10 s between each invocation

To use your local network with client binaries you have to:

  • delete or rename “SAFE Browser.crust.config” file in safe-browser directory (to connect to your local network instead of test 17)
  • pass any string for invitation

#20
$ cargo build --features "local-network" --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/Thierry61/routing.git`
    Updating git repository `https://github.com/Thierry61/crust.git`
error: failed to load source for a dependency on `crust`

Caused by:
  Unable to update https://github.com/Thierry61/crust.git

Caused by:
  failed to clone /home/folatt/.cargo/git/db/crust-8c8d4c67f38703cc into /home/folatt/.cargo/git/checkouts/crust-8c8d4c67f38703cc/2237fa3

Caused by:
  [5/-1] error inflating zlib stream

[update]

It builds with sudo.