This wiki is now locked - both user registration and edits (except by admins) are disabled. We're currently migrating all the content to our new wiki. If you have time, please register and help us out!

You can still view the source code of every page. Once a page has been copied over to the new wiki, please add a link to it to MigratedPages (the only page which is still editable), to notify the admins to go and blank it.


Seednode collection


For opennet to work out-of-the-box, we must have some means to gather a (central) list of seednodes for distribution with the node. The criteria for a node being a seednode are that it is port forwarded, has reasonably high uptime (50%+), that it has the "be a seednode" option enabled (it is by default), and that it has average bandwidth. Beyond that it's a question of trust.

There are various ways to do this:

* A simple manual list.
We could simply publicly ask for people to send us their opennet noderefs. If we are swamped with offers we can choose to only include seednodes run by reputable users/devs/contributors. This hasn't worked well so far, sadly we only have 8 seednode references and they're not very reliable. I also worry about scaling in the event of a slashdotting...

* Trivial push.
Each eligible node pushes its noderef to a daemon on emu every 12 hours. This collector will limit each IPv4 address to one noderef, do basic validation, and provide an up to date seednodes.fref list based on the noderefs it has received in the last 24 hours. Bandwidth is not a problem here (unless we want emu to maintain connections to all the nodes as a form of verification, in which case bandwidth would be a big problem).

* Pull from trusted users.
Each node includes in its full opennet noderef a flag indicating whether it wants to be a seednode. This will be cleared automatically if it has not had good enough uptime, or is not definitely port forwarded. Emu regularly pulls a list of peers-which-want-to-be-seednodes from a set of trusted super-seednodes. This is more or less what we did in 0.5, except that there were less checks on eligibility. It has the advantage that we know for sure that the nodes were connected. The disadvantage is that with a maximum of 20 opennet peers (less if there are also darknet connections), and with a lot of nodes not being eligible, it's unlikely we'd get more than a few nodes per super-seednode. And we did have problems with it on 0.5. We can maintain UDP-based connections to avoid the need to forward a TCP port...

* Collector site with email verification.
We could set up a database backed web page which allows people to submit their nodes to be seednodes, subject to an email round trip test, rate limiting, IP-based limiting, email-host-based-limiting etc. We could ask the user in the post-install wizard, after they have chosen to enable opennet, whether they want to be a seednode. If they do they must enter their email address and do a round-trip verification. If it was done through the node updating would be easier.

See also

SeedNode
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki