Tuesday, January 17, 2017

Bear with Netsukuku

Here we go with another "status report" for Netsukuku 2.0.

I have not much new to share with you guys. The goal remains the same and the work is being done. But the completion is still far away.

It's a lot of time since last post to this blog. Nevertheless I see that every now and then someone reads it. So it's worth to spend some minutes to give an update.

As I stated above, there are no features that have been removed from the list. I still aim to release Netsukuku 2.0 as a modular and maintainable software well documented, with a focus on scalability and stability of the network from the point of view of the users.

The following will be addressed, at least initially in a experimental and rough way:

  • Anonymity.
  • Exploitation of multiple disjoint paths to a destination.
  • Voluntary (not enforced) mechanisms to pay (motivate) the relaying nodes for the most used destinations.

What kind of issues did I encounter that have been contributed most to make the finishing line farther and farther? It's not simple to give an answer to this, and it's not the aim of this post. You could have a look at the commits to the various modules in GitHub, even though I realize that it's not its aim either.

Anyway, bear with me some more time. Having somewhat adjusted the estimated time for each of the remaining subtasks, I may go so far as to predict, now, that the software will be released sometime around July/August.


Tuesday, August 9, 2016

Status report, again

The work towards Netsukuku 2.0 is going on.

My previous estimate was quite wrong about the time needed to finish some tasks. I will not be able to release it until december at least.

By the way, I did not mention that I passed the code onto github. And the main site doesn't mention it either.

You can now have a look at the code and the documentation here:

https://github.com/lukisi
https://github.com/lukisi/documentation
 

Wednesday, April 6, 2016

Brief status report

The work is progressing quite steadily. Alas, I have been in need to change a little the road-map a few times. As a result the finish line has been postponed from "sometime around June" to "sometime around July".

Saturday, February 13, 2016

Why are we going to 2.0 ? Fourth post

Stability

The new version of Netsukuku will provide a more stable network experience and some more new features.

More stability means that in very few circumstances an user of a Netsukuku network will have even a little perception that the properties of the network have changed.
The network may change, for example, in order to make room for new participants, or because two independent networks have joined together. The change might involve only few nodes, but it might also involve many nodes. In particular, the change might very well involve your node or a node that you are accessing in some way.
Even in these cases, most of the issues are managed in such a way that the user won't even perceive that change: active TCP connections will stay up and working; name-resolution mechanisms will be quickly updated. Routing informations won't get lost.

New features (still experimental) will include:
  • anonymity
  • exploitation of multiple disjoint paths to a destination

Status report

Sorry for being very lazy in giving to you updates on the progress of the work.

My last road-map states that sometime around June the software will be complete. I mean that I will be able to make a prototype device or at least some meaningful simulations.

Wednesday, June 3, 2015

Why are we going to 2.0 ? Third post

I have another cookie to share with you about the advantages that are coming with the rewrite of a second version of Netsukuku.
The modularization work has brought the code to a point where the critical sections about multithreading have been refactored. Without going through too deep details, this has to do with the fact that Netsukuku code makes use of lightweight collaborative threads (also known as microthreads or tasklets).

The old implementation in python was using Stackless Python for this. The new one in Vala is using GNU Pth.

The good news is that this modularization work is going to make it easy to plug in another implementation of a "tasklet" system.

This is good because GNU Pth poses some problems. For instance it is common in a glibc-based operating system, such as most Linux distributions. But it has problems with a uClibc-based system, such as default builds of OpenWRT. Furthermore it's not on Windows.

Hence, next version of Netsukuku will be more easy to port to Windows.


Tuesday, April 14, 2015

Why are we going to 2.0 ? Second post

Modularity


Modularity is another reason for the rewriting of Netsukuku.

The software is being structured in modules, with the aim that each module will be able to operate independently from the others and has no knowledge of the others.

This modularity has advantages. The implementation of simulated network environments will be possible, that will prove the correctness of each aspect of the whole system, putting apart the other ones.

For an example of that, let me introduce the Neighborhood module. This module is responsible for the detection of nearby nodes through a number of NICs. Furthermore, it has the duty to periodically measure the "cost" of the link to a neighbor, expressed as the latency of a message through it. Finally it has to detect when a link becomes unusable.

This module has been already well documented and an implementation has been completed. Then, a testbed has been prepared (both a simulated and a real-world one) that allowed me to verify the behaviour of just this aspect.

The tests have highlighted a couple of problems with the mechanisms of the old implementation, which were an issue in particular when a network segment was under load. And allowed me to explore some adjustments and finally find a good solution.

Status report


There are two other modules that have been documented and for which I feel that the current approach is the final one. The coding phase is going on for them. They are the Qspn and the Peer-Services.

The Qspn module is responsible for the exploration of the network in order to give to each node its knowledge base of the network graph.

The Peer-Services module lays the basis for the creation of peer-to-peer services.

Then, some more aspects of the system have to be addressed. I don't want to bore you with details. A complete release will be ready, I hope, before winter.

Tuesday, March 31, 2015

Why are we going to 2.0 ? First post in a series...


An important reason for the rewriting of Netsukuku 2.0 is the fact that a good documentation is being written, at the same time, for each software module.

There is an overview of the problem that the module addresses and how it is solved.  The problem is described as a whole, but at the same time in a precise and detailed manner.  Also, the role of this module in the solution of that problem is described in details.

Then, the algorithm is described that implements the role of the module. The algorithm is described in great details when it is the case, although using a "pseudo code" language. To the point that it would not be difficult for a developer to follow the steps and write the code in his favourite programming language.

Not all the modules, that will make up the full app, have been described yet. However, if one has already read the old Netsukuku documents written by Alpt and companions, he could easily guess which modules are yet to be described and how they should be integrated in the whole.

There is a problem with this documentation, that is it is written in my mother language: Italian. Since it is a work constantly in progress, I'm not going to translate it into English soon. Do not hold your breath.

At this link you can see the most recent draft of the documentation: https://lab.dyne.org/Netsukuku/ita/docs/development