All of us at MaidSafe would just like to extend our gratitude to everyone that took part in TEST 2 last Friday and Saturday. The SAFE community made up the majority of the nodes on the network with 790 nodes taking part (MaidSafe had 200 running), more details on the TEST 2 findings below. The next iteration of testing will be coming very soon, as usual this will be communicated to the community here on the forum. The SAFE Network truly belongs to everyone!
We will hopefully be adding the ability for separate networks and separate network tests this week. This will allow various “testnets” to be created and run by the community for further deep testing. We think the community may offer greater help if we can provide easy mechanisms to test. Also projects like safex, decorum et al’ can then run their own testing networks, either locally or publicly. This will involve starting a Vault with a flag such as --first --name=”your test name” . This is an observation from the forum we took on board this week, along with the updates we are carrying out.
Another push will be ARM again, to ensure this is part of the auto deployment scripts we have for creating installers as we tag releases in github. This will help everyone a lot.
Archive nodes are under the microscope again to ensure data is maintained even in a full network outage or worldwide catastrophe. Work is progressing there in finalising some RFC’s for implementation. In addition, the node names will be further secured by the network challenging nodes to create appropriate keys within a range, this allows less message passing and self-validating messages as we have with the client.
The push is for a stable network first then increase security second when we can easily upgrade and allow a data republish mechanism (archive nodes again). So we strive for a stable network and client API’s. The march continues there strongly with many great findings from some amazing and highly appreciated community involvement.
##Community TEST 2
Routing showed greater stability - we didn’t observe any mass disconnects in this test and even after stopping all 200 droplets at the same time, some community nodes remained connected and formed a working network. Toward the end of the test, Vaults became prohibitively slow and in the end stopped working entirely and even joining as a new node could take multiple attempts.
We suspect that the upstream / downstream bandwidth asymmetry might be the reason: our crude message prioritisation is probably what saved most of Routing (small messages) and overwhelmed Vaults (large messages with data chunks in them). The logs also showed lots of delayed GetNetworkName responses that would have allowed a new node to join but couldn’t be delivered because that node had already timed out and restarted.
##Crust : Andrew / Spandan / Vinicius
The team progressed quite nicely in evaluating current solutions for asynchronous interfaces in Rust and developing prototypes. A lot of solutions were ruled out and we started building a few foundations on top of current knowledge to allow easy composability of different crates that can share the same thread. Experience from other communities besides Rust was taken into consideration as well to avoid errors like unfairness, jitter, starvation and a few others. @canndrew has done a few experiments with coroutines and we hope to have that integrated as well. Coroutines can greatly simplify code readability as we keep the usual control flow mechanisms (if, while…) in asynchronous code. It looks promising.
##Routing / Vaults : Adam / Andreas / Fraser / Qi
We reproduced the issues we saw within test 2 on the droplets by artificially restricting their bandwidth and emulating home network connections. We are now testing with the more fine-grained message prioritisation that distinguishes between messages that are essential to the integrity of the network and messages that can be dropped if the bandwidth is not enough.
In parallel, we are looking into ways to deal with messages dropped in the upper layers to make sure that we don’t lose any client accounts, for example, even if the nodes in the client manager group went out of sync due to heavy churn.
Further work is going into automating the building and packaging of the Vault binaries on all platforms and resolving the remaining issues we are seeing on ARM.
##Client : Krishna / Spandan / Shankar
We are improving the log visualiser and also updating the droplet deployer tool to help the internal dev team test the network.
The priority for this week is to address the client side issues (safe_launcher) experienced during last week’s test. On occasion the Launcher was hanging. This issue has already been reported by the community members.
##UI Design: Scott
@scott is continuing work on the website design. The focus with this work has been to create a unified and coherent experience which fulfils the identified company goals. The design work for the site is wrapping up and soon we will begin implementing the changes.
Thanks as always for your support, here is a link to the weekly transcript.
These are API requests starting at April 1st this year:
Well, running a vault was really easy. This thing is a good work made by maidsafe team. Kinda “plug 'n play”.
