>(Greg Wooledge wrote:) >> >This is not the latest build, but it should work if you can get >> >some working node references. Mine are at >> ><http://wooledge.org/~greg/seednodes.ref> -- stop your node, download >> >that, replace your current seednodes.ref file with mine, and restart >> >the node. Give it a moment to catch its breath, then try the four >> >keys on the gateway page again. > >> this is the topic about this mail: seenodes.ref-bashing *grin* "kill your >> noderefs by overwriting with my file" - destorying some of these rare >> noderefs. > >No, the seednodes.ref file does *not* get updated during the course >of the node's operation. There's nothing rare or unique in the >original person's seednodes.ref file unless he customized it himself, >which I sincerely doubt is the case. More likely, it's just the >vanilla seednodes.ref file that you get when you run the Windows >installer. > >The rare and unique node references that each node has (i.e., the >routing table) is actually stored in the datastore. It is *not* >stored in the seednodes.ref file.
duh... okay.... :) >Since the original person's node was *not* able to contact any other >nodes at all, replacing the seednodes.ref file -- which adds >*additional* node refs to the routing table, and does not remove >any node refs from the routing table -- is a quite reasonable course >of action. i agree. if somebody cannot access any of the standard refs, replacing with a more mature file is appropriate >> what i am thinking of is a simple-to-use "import another seednodes.ref to >> your node". > >That's exactly what my suggestion achieves, minus the "simple-to-use" >bit. The only way I can immediately think of to make it easier >would be to check the timestamp on the seednodes.ref file every >once in a while, to see if it's been replaced -- and if so, to read >it and import the new refs into the routing table. This would burn >some CPU time in stat()-polling the file. (Err, whatever Java has >in place of stat().) I can't see it happening frequently enough to >make this trade-off beneficial. this seems to be another way, but this would still use *one* import file. if you put some seednode.refs within a separate directory you can store all import files there, without feeding fred the first file, wait some until he ate it, then overwrite with the next, wait again,.... >The rest of your message was built on a misconception, so I've >snipped it. :-) sorry about that ;) perhaps the ds-ed seednodes could be flushed once in a while to disk for easy access (keep calm, that does not consume excess cpu%), but i know there is already a way in exporting it manually >-- >Greg Wooledge | "Truth belongs to everybody." >[EMAIL PROTECTED] | - The Red Hot Chili Peppers >http://wooledge.org/~greg/ | > ____________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
