###UPDATE : Bug in launcher fixed. Please update to latest version.
In this Dev Update we are all very pleased to be releasing and sharing with the community - the TEST 4 network
As with previous community TEST roll outs this is a temporary network and will be taken down after the team are happy it has met its objectives. So what are we focused on with this test release? This iteration includes many changes in code with the goal of significantly reducing resources / messages / bandwidth handling, etc. We are testing that accounts are stable and that community members participating are able to log in and out as they like without experiencing issues. There will be a few steps to take yet before achieving absolutely persistent data, but TEST 4 is a very large step in that direction.
###Get involved in TEST 4!
Please be aware this release will not allow older nodes or clients to connect to the network. You must use the new binaries below to connect to the TEST 4 network.
This is a test network and comes with the normal risks of using pre-release software. Please also be aware that this test network and will be reset, wiping all data that is stored on it.
###Where should I report issues?
GitHub is the best place to report issues and bugs. Using GitHub will help us (MaidSafe) manage issues and prioritise work within the Dev team faster.
If you are not sure if it is a real bug and have a question, the forums #support category is a great place to post this. As we know this is a friendly and responsive community and someone will help you out and of course as always - thank you for participating in TEST 4, it really does help.
##Crust, Core: Andrew, Spandan (tl) & Vinicius.
Crust async has now been merged to master and published to crates.io. We have now successfully redesigned it with State pattern and integrated with MIO. Due to a bug on MIO in crates we are depending on our temporary fork with the fix until the MIO guys publish the fix which we have raised for them.
The number of persistent threads in crust is exactly 1. Previously we would have multiple threads per connection leading to a huge number of context switches which was inefficient. It was not uncommon to see more than 200 threads for a little over 60 connections (Routing table size > 60). Now in many of our tests where cpu would constantly hover around 100%, we have cpu now calm at around 1-5% and rises to 30% temporarily only during peak stress i.e. a lot of churn and data exchange.
All system calls are now async. Crust has had a switch from application level concurrency primitives to operating system level concurrency. With the new event based mechanism, if the kernel is not ready for some state we steal that opportunity to have it service some other state it is ready for which keeps the event pipeline hot and optimal.
Bootstrapping is also parallelised. This increases the speed of bootstrap process. Previously the sequential bootstrap meant we went to next potential peer only if the currently attempted one failed. Crust also allows for blacklist support during bootstrap so that Routing can specify which peers are not advisable to connect to because for example it concluded that this peer had suboptimal Routing table size.
The Crust config file has been cleaned out, removing deprecated options. This is because we have improved the design by integrating stun services into connection listeners instead of having them as separate peers / processes.
##Routing, Vaults: Adam, Andreas (tl), Fraser & Qi.
We finished migrating to the new mio-based Crust, as well as implementing the message splitting and group message deduplication, which should greatly improve the network’s ability to handle high traffic and is showing promising results in our tests. We also finally (hopefully) fixed the remaining issues affecting ARM and 32-bit x86 and will release binaries for these architectures as part of TEST 4.
We are now putting some effort into extending our tests: The Routing code is very complex and we will need to better modularise it soon; extensive tests will make it a lot safer to make large changes to the code’s organisation. Most of the work will go into the local tests with a simulated network (“mock Crust”), but we also augmented the tests we do on actual networks e.g. by throttling the bandwidth to simulate different kinds of internet connections.
##Client : Krishna (tl), Scott & Shankar.
The RFC is accepted and active, with the Client team busy implementing it.
Last week we focused effort on RFC implementation planning and also on getting the safe launcher CI to automatically build and tag its release across all three platforms. Previously we used to build launcher manually for all platforms and releases, with this in place it does save the team a lot of time, especially during the final minutes of rolling out a release.
We are hoping to wrap up the RFC implementation by next week (24th June) and release the safe launcher v0.5 by the last week of this month. We hope the next version will improve the user experience of the demo application as well.
The guys are also working on improving the launcher experience as well e.g. an account’s storage statistics will be displayed on the launcher based on the number of puts as explained by @viv in his forum post here, @scott has designed a mockup for presenting an account status to the user (see below).
The whole MaidSafe team has worked extremely hard to deliver TEST 4 - the next stage of the community test network rolling release. Progress is clear to see, we hope many of you will get involved in this testing stage and we look forward to all of your feedback.
Thanks as always for your support, here is a link to the weekly transcript.