IOTA

One feature that I look forward to implement in the first experimental deploy of the Netsukuku network is the ability to send economic rewards to nodes.

My choice for this feature is the IOTA token, mainly because of the zero-fee feature of the Tangle DLT.

IOTA is quite new compared to Bitcoin. But obtaining IOTAs (and getting back Euros) is nowadays quite straightforward.

These are my first impressions about a new exchange, MercuriEX, which is one among the first (AFAIK) to take advantage of the use of the Hub module from IOTA Foundation.

Quite adherent to the IOTA principles, the fact that there are at the moment no fees for trading.
I am not a fan of "for a limited time" features, and I sure hope they will try and find a practical way to extend that feature for more time.

I find the UX quite simple to understand. The charts are at the moment not very feature-rich, to be honest. I don't seem to find a way to stretch the time span.
In general I think that this UI will need to become richer with time. The exchange is very young.

Of particular note the easy and quite immediate process of getting an account. At the moment your choices for trading pairs are limited to LTC/BTC, MIOTA/BTC, ETH/BTC.

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.

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
 

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".

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.

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.

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.