There are a few reasons why I suggest NOT putting this into the core Freenet server (fred) and instead put it in a seperate component. First, fred is too huge already. If its possible to implement the functionality outside of fred, it should be. Lets learn from the experiences of the past and build small interoperable components rather than monolithic apps.
All of the information required to do what you've described is either currently available or could easily be made available to external apps - failed keys, the current load, the bandwidth status, and the ability to submit requests. If this node assimilation vs normal mode is really desired and has been proven to improve the health of the network, it can be packaged as a download and added to the standard startup scripts. This lets us try it out with "low risk" to the health of Freenet. Maybe it works out, maybe it doesnt. Maybe it has some implementation or tuning issues, etc. Down the line though, I can't imagine a scenario where we would want to compile it into the core Fred though - doing so just tightly couples something which doesn't need to be and makes both tuning Fred harder modifying it more complicated. You're definitely going to want this assimilation mode to filter by keys - e.g. skip all KSKs as those are used largely for transient inserts (and are inherently floodable). There is also good reason to believe that excessive use of this assimilation mode can be harmful to the health of freenet, as it dampens the ability to migrate data to where it is desired - this node in assimilation mode may never ask for that key again - which is why I think you'd also want some form of user control over it as well (e.g. telling it to prefetch certain keys periodically). > Does FProxy behave as a node, or is it accessing Fred directly? FProxy runs in the same JVM as Fred, but it is just another client application - it uses FCP to communicate with Fred to make requests (via FCPClient via AutoRequester via FProxyServlet). FCP, the Freenet Client Protocol, is used only for applications to communicate with Fred, as opposed to FNP, the Freenet Network Protocol, which is used only for nodes to talk to each other. You're right in that FProxy (specifically AutoRequester, I believe) keeps searching down the key through any metadata it retrieves to find what its looking for (though the algorithm is a little more complicated than just searching until it finds a CHK, but basically). There is no way for Fred to know the difference between a key that contains a Redirect or DateRedirect metadata line and one that does not - you can even create a set of CHKs that contain Redirects through a big long chain of keys if you so felt like it. I'm not sure that's a problem, as not only is the data the "hot potato", but the metadata is too - which of the files in the metadata should be retrieved? The one arbitrarily named "index.html", "description.txt", "activelink.png", or all of them? There's viable "business logic" in the operation of this re-request functionality, this "assimilation mode", which means there is room for choosing different methods of implementation. It has merit, and could be very helpful for new users and to help improve the perceived performance of popular sites, but with so many variation points, I'd highly recommend factoring it out into a standalone app (bundle it with fred, provide replacement startup scripts, *maybe* even run it in the same JVM, but keep it as a seperate component). At least, thats my take on what I think you're proposing. -jrandom !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ CryptoMail provides free end-to-end message encryption. http://www.cryptomail.org/ Ensure your right to privacy. Traditional email messages are not secure. They are sent as clear-text and thus are readable by anyone with the motivation to acquire a copy. !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
