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.