MaidSafe Dev Update :safe: 26th April 2016

Back into the Tuesday Dev Update cycle :slight_smile: . As you will see from the section below about our findings from Thursday’s testing roll-out and the individual library sections, most of the team have focused on implementing improvements into the next network iteration. The guys are currently testing these and once happy we shall roll out new binaries ready for the next phase of community testing.

@adam has been busy working on automating the deployment process by implementing rust_everywhere into our CI system to automatically create Github releases on every version bump. He is also implementing auto Docker image creation, so deploying an up-to-date Docker container should soon be a very simple task.

So a lot has been happening since last Thursday, on with the update…

##Findings from the last testnet iteration

Firstly, thanks to those who participated in last week’s community testing phase, your participation is extremely helpful and is very much appreciated. As covered in forum posts from @dirvine and in yesterday’s Pre-Dev-Update Update post, during the testnet we found improvements in:

  1. Churn handling (we were way too aggressive there);
  2. Network segmentation prevention (this one was really important for us);
  3. Huge improvements in mass network startup;
  4. Improved error / warning messages for early testers.

For more detail on how these findings have shaped the Dev team’s focus and efforts since Friday it is well worth checking out yesterday’s forum post (link above). I will not duplicate everything here, but as David pointed out it was indeed enlightening and helps move us forward towards our ultimate goal - launching the network.

We have been testing the next Vault release (which incorporates these improvements) today internally and the Devs are keen to ensure that the community experiences increased stability in this test roll-out.

##Crust - uTP / API : Vinicius / Andrew

Heartbeat has been implemented in Crust and code is becoming less vibrant and now more stable. It should be no surprise if we start to focus full-time on the refactor soon. The refactor shall focus on efficiency and using asynchronous patterns that are more scalable than what we currently have. The improvement work that the guys are currently undertaking in Crust is happening in tandem with the existing working version.

##Routing : Adam / Andreas / Brian / David / Viv

Routing now better distributes and sometimes throttles accepting new nodes, to give them more time to integrate into the network’s structure. We also removed some obstacles for re-connecting nodes, so that even after extreme churn, the network is better able to repair itself.

We didn’t increase the limit of three tunnel client pairs: each node will at most replace failing direct connections for three pairs of other nodes. If there are a lot of Vaults behind routers where NAT hole punching fails, this will most likely break the network.
To reduce overhead, Routing now prunes connections that are no longer needed and puts more routing table information in the events it sends to Vaults.

##Vaults : Andreas / Brian / Fraser / Qi / David

Event handling is a lot more efficient now due to a small change to the Routing API, message traffic between the two event handling threads is now greatly reduced. This is only a temporary workaround, as in the future we plan to have only one event handling thread.
Data relocation traffic has been somewhat reduced by de-duplicating messages and often sending only a hash instead of the complete data. The main part, however - throttling relocation and giving the nodes as much time as they need to transfer the data - is not yet implemented, which is why we still have low limits for the Vault size.

##Client - Launcher : Krishna / Spandan / Shankar

Last week the safe_core was updated to work with the latest Routing version and released for the test.

The log visualiser is being tested and the first version of the log visualiser server will be used by the internal Dev team. The first version is a simple tool, which will allow the Devs to filter logs and export the logs as a .csv file. In time, more features will be added and shared with the community members for connecting and monitoring their Vaults.

This week we are hoping to get back to the RFC which is waiting to be raised for the Launcher standards. We are looking forward to discussing the RFCs in the open and getting them to an agreed state, which will allow us to begin to plan the tasks and start with the implementation.

##UI Design: Scott

Last week @scott scoped out and conceived a number of changes to the MaidSafe website with an aim to improve the UX and better match the company’s objectives. Work began last week on designing solutions to these issues and working with @shankar on their implementation.

@scott is also working on the design of a network status dashboard, where users can view data about the network and filter results by vault ID. Work has begun on exploring which data would be useful / interesting here and also on ways to represent it compellingly.


Thanks as always for your support, here is a link to the weekly transcript.

52 Likes

Great! Looks great!

First comment :smiley: first time for me.

Posted 1min after update. Read the whole thing before posting I promise!!

Edit: The live network status website idea sounds great!

8 Likes

Fantastic work all!!

A few quick questions…

Will there be any updates to test network of vaults (uTP, etc?) or any plans to make adding a vault a bit easier for us dummies?

Will the test network be wiped?

3 Likes

Hey Ross, thanks for keeping everyone in the loop and all the hard work you and the team do. Please pass on my thankfulness…

I’m not looking for a promise or anything just an estimation. Are you guys planning on Thursday for the new binaries release? or later tonight? or next week?

7 Likes

They are testing the Vaults and release them when they’re happy…

So I think it all depends on that. If all goes well, maybe this week? That’s my guess. And if a nasty bug show up it could be next week. I think even the Devs can’t say for sure.

11 Likes

As @anon40790172 advised above, just as soon as we are happy with them they will go out.

9 Likes

Right, that was my confusion. when is the “next phase of community testing” today? thursday? next Tuesday? honestly I don’t care too much. I don’t plan on crucifying anyone if something goes awry, but simply plan my week so I can support and be aware of the releases I want to know. That’s all.

@anon40790172 @nicklambert never mind! :stuck_out_tongue:

3 Likes

Great update @Ross Good to see you didnt set any traps for yourself and your team by giving estimations. Should keep the forum gang-banging to a minimum. Look forward to surprise updates.

6 Likes

This is nice. Sounds to me like the binaries are coming more easy :yum:.

Here’s more information.

Use CI services to generate binary releases of your Rust program for Linux, Mac and Windows
This repository has configured Travis CI and AppVeyor to generate binary releases, in both tarball/zipfile and deb (*) format, of a Cargo project (in this example, a variation of hello world) for all the tier 1 platforms and some lower tier platforms whenever a new git tag is pushed.

3 Likes

I get where you are coming from on that…I guess a very basic question might be, can we expect updates or new releases throughout the week or are they going to be held and all released on Tuesdays…that would at least let people know that if an update or new features have been completed, they can be excepted either ASAP or it will roll out on a set day of the week…

5 Likes

exactly, you got me bro.

2 Likes

Why would they wait for a Tuesday to release binaries when they’re tested on Thursday and are okay? Like Nick said, when they’re happy with them they will release them. The first iteration went live on a Friday night.

3 Likes

Well, because my brain is mush and I needed a little clarity :seedling: that’s all.

2 Likes

“We didn’t increase the limit of three tunnel client pairs: each node will at most replace failing direct connections for three pairs of other nodes. If there are a lot of Vaults behind routers where NAT hole punching fails, this will most likely break the network.”

That reminds me of that voice in the Maidsafe overview video: “There’s a reason this is called logical.”

What isn’t logical is selling game-changing technology for some barely rising Bitcoin. Haha!! They don’t deserve to be called even day-traders! But I regress…

Oh no, they’re the only ones regressing (once again: in their logic).

Thanks for amazing work and amazing times. Building logical steps one process at a time.

7 Likes

I think it is a good choice not to use the word MVP in the following dev updates :slight_smile:

2 Likes

Just for info on where we are this evening. Testing on live networks via droplet deployer. We ran the network several times today.

Good news :

  • With Tcp we seem to be punching holes in routers - so yes much easier for folks to use. (big well done crust team) [btw Utp is there, but is very slow just now, so disabled for the test]
  • Routing behaves extremely well and recovers via vault layer on routing table issues (quietly).
  • Generally - all working as per expected … but (there is a but)

More work news:

  • The network behaved to a point where we stressed it by randomly starting vaults from behind routers - all good
  • Then churning vaults a lot while creating accounts and websites etc. we seen some disconnects.
  • we could push to the stage logins were delayed or seemingly lost.
  • Later this afternoon we looked further into traffic and noticed quite large amounts in vaults.
  • This traffic can grow to such an extent that nodes lose heartbeat signals and disconnect (heartbeat may be too aggressive)

Actions

Tomorrow morning we will alter the vaults to not send multiple copies of data multiple routes, but instead trim this to sending one copy. This is a big reduction in Get traffic. So good, not a long job to change that.

We will also reduce GROUP_SIZE And PARALELLISM counts to lighten the load there. This allows a quick change to traffic and get on with tests in the community. It will take 1-2 days (or more) to fix more correctly and we do not want to wait too long.

We also have a couple of less important changes we can make in routing which are too much to go into here. Basically there are a few loose ends and we will try and get through them and get test2 stable quickly.

So bear with us, we are going like the clappers right now to push through this and we do need to fiddle some knobs, but that’s all it is right now. There is just an awful lot of them :smiley:

The network we test on is only 100 nodes, but it really should be several thousand nodes to be honest. That’s not great, or so it seems. In fact it is great, we get much less stability and we see faults that would be missed in much larger networks. So in this way we actually can drive edge cases quickly. Nice to be able to do that before a larger network exists in many ways. So basically it suits us to push these edge case errors right now.

Then we will run up the network again to check aggressive churn. If all is well we should have some binaries in your hands again very soon, but we do not know if these quick changes are enough till we again measure. We are not looking for perfection or engineering excellence here, but to get this stable enough where larger community tests can help. They do help tremendously and with Rust we can now make changes quickly when we see them, so that is great.

So you may think, this all sounds weird, surely these tests have been done, but no, we have not had a live network working like this to measure. So this is really at the stage the cars on the track and we need to alter some valves etc. No big issue, but we are doing it as much in the open as we can.

One issue from Thursday we only cleaned a bit is the error messages. They are better now, but still very developer like. These will not yet be good enough user facing messages, but will be a bit better. Next test will have much better user facing ogs and much less detail.

I have seen some frustration on the forum, so will try and communicate these points as we go along. Many devs do not read it, so good they will not be under as much pressure that way at the moment. All eyes on testing really is what we want.

I will try and give mini updates over the next few days as we move on. It will maybe keep everyone a bit more in the loop.

Exciting days, but a wee bit of pressure thrown in :wink: All good.

46 Likes

Yes we have been discussing the terminology internally and will be simplifying this in the coming days.

10 Likes

But the market cap of BTC is huge, which means my profits will be huge, right? Oh, wait … :confused:

3 Likes

Yeah! :sunglasses: This is great news.

7 Likes

Punch those routers to bits! (or MAIDs)

6 Likes