I've just created a new "branch" in the SVN repository
(https://gnunet.org/svn/gnunet/) which contains about 50 kLOC towards an
implementation of GNUnet using a radically new architectural redesign. The
code there only has TCP support and no real applications, but basic
(encrypted) messaging between peers is working. In other words, this is not
useful for anyone but developers and those interested in contributing to the
discussion as to how the code should evolve. Note that development on the
existing 0.8.x-branch is expected to continue (albeit at a slower pace) for a
while. Once we've sorted out the quirks in the new tree, moving existing
applications from 0.8.x to 0.9.x should not be too much work.
I want to briefly state the main advantages that the new architecture will
1) Fault isolation. We're using more processes, literally replacing all
threads, which will ensure that if one component crashes it doesn't take the
whole system down -- and we can tell *which* component is responsible, as
opposed to component A corrupting memory and the code crashing in component
B. Also, 1000 lines of locking code can disappear.
2) Language independence. Since plugins into the framework run as independent
processes, it will be easier to contribute to GNUnet using languages other
3) We're also addressing various long-standing API and protocol issues,
including more consistent naming conventions, better support for multi-
homing and IPv6.
A more detailed rationale describing not only what changed but also why can be
found in the repository at https://gnunet.org/svn/gnunet/RATIONALE.
GNUnet-developers mailing list