> -----Original Message----- > From: panamerica334 at uni.de [mailto:panamerica334 at uni.de] > Sent: Thursday, March 13, 2003 6:04 PM > To: devl at freenetproject.org > Subject: Re: [freenet-dev] Data propagation, node > assimilation, freenet capacity (thoughts) > > > this sounds like a good idea! :)
We'll have to see what the brains have to say... thanks anyway. > although it requires a very high bandwidth connection. also, > i don't know if java is able do determine the network load or > if there is > something similar to guessing the network load coded into fred. Well, we have bandwidth limiting (if it works), and we have that node load indicator, so I assume it's possible to do something in that direction. > perhaps assimilation nodes will increase availability of > neary lost keys, not just filling up the datastores (which is > a damn good thing): Nearly-lost keys should stay nearly-lost, unless they are requested more often, I think. > -> currently i have problems retrieving keys with htl=25 from > node a that were inserted with htl=20 from node b just some > days ago (!!!!) <- > the only chance for me is to retry later or use a different > node c, which might find the key, drag it though freenet, > allowing node a to find it left on the way from > node b->c. > > with the nodes in assimilation mode i/an user would not need > to activate node c to try to fetch that key, because node a > would trigger all b0rg nodes while > looking for the key. > or am i getting the details/the whole design wrong? does only > the request initiator retry to find the key, or any nodes on > the way to the key? Not only the initiator, but also every node in between that has enough bandwidth, load and storage to spare (the trigger of "assimilation mode"). Those nodes would belong mostly to the "fringe" group of new nodes. I'm not sure of the effects it would have to established nodes that have their datastore enlarged. The "assimilation mode" is intended as a helper for new nodes and as a helper to better storage use. To what extent it would be effective, I'm not sure. There is also the question of a feedback effect. That's mostly being taken care of now by the tagging of requests so that they don't loop in their routing and the failure table, but here we are talking of possible hours until the re-submission of a request. That's not trivial! A related thought about DBR sites: DBR metadata is a complication because you have to fetch them anew every 24 hours (the norm). Freesites are in many respects similar to real web sites. There is static (over time) context (e.g. images) and there is variable content (html). A proper mix of content between DBR and Edition-based for a freesite would ensure that static content will be fetched faster because it would not rely on having to fetch the DBR metadata first. If something does change, the publisher can create a new edition only for the replacement static content and use the new key on his links. Is that practical? My experience with freesite creation is limited. [pls. if you answer to this sub-topic, do so separately and change the subject] Doc _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
