Yesterday we entered the third week of the Rust-5 sprint. As Ben nicely summarised last week, we’re concentrating at three main objectives:
- UDP hole punching in Crust
- Connection management in Routing
- The SAFE Launcher in Client.
I’ll start with Crust as that is closest to me at this point. UDP hole punching is ready and we added some new functions to Crust which users can run; holes in NATs are created and we can send UDP datagrams from one peer to another, even if they are behind firewalls (this is testable with our modified crust_peer example). The next step was to use the punched holes with the rust-uTP library. There are some bugs here that we need to solve in Crust to be able to fully deliver this feature and we are working to solution those this week.
Another part of Crust/Rust-5 sprint was a tool to measure, report and test connection reliability. It was created by one of the guys from the community and Fraser, together with Krishna, were working on a deployment tool for this test. As expected, TCP connections are nice and stable and it has also helped us pinpoint some minor issues in the Rust-uTP library which the author of the library promptly fixed.
QA team also made a small but super useful tweak to the CI machines. For some time now, we’ve had the problem that we had to wait for CI machines, often as much as 2 hours, as devs often committed their new pull requests at the same time causing a few of the tests to halt and the default scripts took too long to kill them. Now, if a machine doesn’t finish within 10 minutes (which is more than enough), it reports an error and moves to another pull request. We already feel benefits of this change. On top of that, Ross also started working on building the software on odroids [ARM].
The Routing library still has a few tasks and issues (the issue needs to be resolved before we can test vaults/launcher against even a tcp network, Brian is looking at it now) to complete and this library has also been affected by hole punching, as now connection establishment necessarily needs to include one additional asynchronous step which is the act of figuring out our external endpoint. Yet again, a task which appears minor at first sight but is really a big change in the connection establishment logic, combined with safety guarantees that Routing needs to keep in mind, these guys have a hard nut to crack. The integration of uTP into Routing is blocked by the current bugs in Crust which emphasises the importance of solutioning the Crust issues.
The work on launcher is complete for the first iteration. It was a big deliverable for this sprint with more than 8000 lines of code being committed. In order to test Launcher, we have been writing a compatible test application in Nodejs which we will run against the Launcher CLI coded in the examples section and see how things fare. If everything is smooth and as expected, the first version of the Launcher can be considered to be completed. The CLI will act as an example front-end, a pre-cursor to the Launcher UI that will likely come up in next sprint.
The great news here is that the app-devs can start working on their apps right away! Launcher exposes JSON RPC like convention, so there is no need to know about the internal workings of the SAFE Network to build apps on it. One just needs to follow the JSON API documentation in the RFC.
So, we have made really good progress during this sprint. We spent a great deal more time on planning and this has not only enabled the community to become more involved than ever before, completing around 10% of the points, it has also allowed the MaidSafe team to stay ahead of schedule. The success of the sprint is now dependent on fixing the Crust and Routing bugs although it is great to be able to deliver the new Launcher API to the app devs.
And to be complete, here is also update from Justine.