Posted on flog, uploading.
==
Return of the test network: Part One
Years ago, when 0.7 was first implemented, we had a "testnet mode". You can
still find traces of it in the code. It reported node locations and connections
to devs, and provided some limited access to logs etc.
It has recently become clear that there are bugs in the current code - mainly
related to new packet format and new load management - that can only be
debugged with access to detailed logs on both sides of the connection. It has
also become clear that trying stuff out on Freenet proper is a dangerous
strategy.
So I will be rebuilding the testnet shortly:
* A separate branch, a separate release of the software, a separate
auto-update key.
* A big fat warning on all pages of the user interface.
* All testnet nodes will periodically connect to a central tracker, which
will test connectivity to their testnet port (a TCP port listening for commands
to do things like downloading logfiles), and log basic stats and recent error
messages.
* Testnet nodes will be incompatible with non-testnet nodes, making up an
entirely separate network, but will use the same key formats, so it will be
possible to download binary blobs of content on the main network and insert it
onto the test network.
* All testnet nodes will need a minimum amount of disk space for logs, and
there will be a hardcoded log threshold list (users can add more stuff to log
but not block stuff on that list). We will probably also have a larger
in-memory logfile buffer, so possibly a larger minimum memory requirement.
* The wrapper will be mandatory because we will need to be able to restart
(easiest way to deal with various problems e.g. shutting down routing if we
repeatedly can't connect to the tracker). So will auto-update, probably.
* There will be both darknet and opennet available on the testnet. There
will therefore need to be at least one seednode, eventually.
* To be absolutely clear: On the testnet, all nodes report to a central
server, and developers (or theoretically anyone else) can connect to any node
and download detailed logfiles. Thus, there is no anonymity. However it will
otherwise be running the same code as the main Freenet, so allows us to follow
bugs from one node to the next, and test risky changes before deploying them on
the main network. There may eventually be control functions such as forcing a
node to restart or to auto-update without using the UOM/UOF mechanisms (if e.g.
we have managed to completely break the transport layer), but any such
functions will be cryptographically protected in a similar way to current
auto-update functions.
The immediate goal is to be able to see both sides of the story when something
bad happens at the packet or message level. For instance I spent a long time
trying to debug a problem where a node was acknowledging packets containing SSK
requests, but was never sending an Accepted or Rejected at the message level.
This could be a packet level problem or a message level problem, but the fact
that the packets are acked rules out a lot of obvious possibilities.
The medium term goal is to sort out the remaining issues with new load
management (particularly fatal timeouts). The longer term goal is to be able to
develop stuff on master, then merge it to the testnet branch, have the testnet
network upgrade, and see whether it severely breaks everything, before
deploying large potentially disruptive changes. Hopefully the testnet will grow
to hundreds or perhaps eventually thousands of nodes where we can test stuff.
Stay tuned!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20110217/cde35e9a/attachment.pgp>
