We advised in last week’s dev update that we hoped to be running Routing against the new Crust API, while also integrating Vaults by the end of last week; we did not meet that target. As you will read in the Crust section this has only been pushed out by a few days, so is in no way a major setback, the revised estimate is now to have this completed for the end of this week / the beginning of next. The team have been working like crazy and will be as elated as all of you when we can share the news that RUST-5 has been delivered. Thanks as always to the Dev team for taking time out to help make this update happen, it is definitely appreciated by me and clearly - from the support and feedback we receive each week from you guys - the community as well.
##Crust - uTP / API : Vinicius / Andrew / Spandan / David
Utp: Since last week there was a lot of work in rust-utp and we finally merged the branches that fixed many of the serious bugs found in the library. Hopefully there isn’t much more work to complete before we declare uTP stable and start using it in the upper layers.
Beacon: This part was re-implemented yesterday and today and will be pushed into a new crate specifically for service discovery (discover services (nodes)) on a LAN via Udp.
File_handler: Again pulled out of Crust into its own crate specifically for handling config files for any application that requires this. It provides a consistent approach to any config items people will need for apps. Client app builders who use Rust can happily use this crate for “safe” config file handling. We do attempt to lock the data where possible via memory mapped IO.
Crust: The internals of Crust were heavily refactored last week and this will continue this week as soon as the above crates are API ready (today / tomorrow at the latest). We removed a “state” object (and unstable callbacks) which essentially locked all messages and connections in one place. This was a perfect example of a situation that would have slowed down message flow, never mind have greater potential to introduce deadlocks. This much slimmed down, safer codebase should hopefully provide us with a significant increase in message throughput.
As an aside we are implementing service_discovery with mio. This may extend into Crust core and if so we would expect message throughput of over 60,000 messages per second. This will give us a really nice buffer for the future as well as using operating system async IO such as epoll, kqueue etc. This again means the ability to significantly reduce resource use and increase performance to closer to OS capable speeds. A pretty significant change from a users perspective as it is less threads and more low level IO.
##Routing - Vault Integration : Andreas / Brian / Adam / David
We worked on the precision of the theoretical model underlying our generalisation of the Kademlia routing mechanism to make the foundation on which the network is built bullet-proof in a way that can be verified with mathematical certainty.
This week we will make some adaptations to the routing table implementation and to the Routing library itself to fully align it with that model and we will add tests to ensure that it does match the model and to test the model’s theoretical guarantees in practice. @AndreasF has created an RFC which goes into this in much more detail.
##Vaults : Fraser
As per last week, progress has been slow on Vaults since @anon86652309 is covering for @Viv. However, the message flow is complete to the point where Vaults should in theory be functional again. We’re waiting for the changes in Routing to be completed before actually running up a Vault testnet again.
In the meantime, focus is on re-implementing unit tests and tests using a mock Routing implementation.
##Messaging : Qi / Brian
The implementation of a slightly modified and updated, with respect to what was initially agreed, MPID-Messaging RFC has begun. Completion of the Jira tasks should allow a basic command line example to be written showcasing a functional messaging system between nodes. In implementing this messaging infrastructure it will also be possible for third parties to start creating secure messaging apps.
##Client - Launcher : Krishna / Spandan / Shankar
Last week the focus was very much on planning, with tasks being created and detailed for the implementation of Launcher. The implementation work for the Launcher is beginning this week and @Shankar will be joining the Launcher and Drive application implementation. It is going to be an exciting and busy two weeks for the Client guys.
##Roadmap : Scott / Shankar
@Shankar was quick to implement a configurable module for the Roadmap. The actual data for the Roadmap has yet to be integrated; once the implementation has been reviewed and accepted internally, this will be added. Once complete, the roadmap will be added to the new website.
##UI Design : Scott
@Scott has been working on storyboards and mockups to be used when talking with potential MaidSafe investors. These are designed to aid conversation on user-focused parts of the network. The storyboards are simplified, visual walkthroughs for some of the key use cases we’re catering for.
Thanks again for your time and support, here is a link to the transcript.
that depends on what I mean by launch. So Ill ask it this way. Are you concerned at all that you may not be able to complete this to a live network with SAFECOIN without new funding?
