First a comment to the original proposal of this thread. I basically like the idea proposed. However, as I attempt to explain below, it may not be necessary (IMHO). I don't think there would be any harm in making it available as a feature for those who want to use it.
On Saturday 09 March 2002 10:46 am, you wrote: > > An alternative that I have tried and it seems to work is to periodically > > retrieve your files. > > "Seems to" is the key phrase. It doesn't provide any kind of guarantee, or > even improve availability by any determinate amount. Furthermore, as more > people join the race to stay at the top of everyone's cache the benefit to > each decreases...while network traffic continues to increase. At a certain > point this becomes tantamount to a deliberate denial of service, and should > be treated by the network as such. I think what some people are suggesting > here is something that improves availability deterministically and without > increasing network traffic, even if it ends up being less than an ironclad > availability guarantee (which might not be possible in this context). If you are using a large store (much larger than the total size of all the files you want to serve) then shouldn't the impact be fairly small on your neighbouring sites? Your own store will mostly hold the files. Also the time between retrievals can be adjusted to be a minimum sufficient to keep the files in the network. It seems to me there are two possible scenarios: 1) The total freenet storage is sufficiently greater than the amount of data being stored that the network is only somewhat lossy or 2) the total freenet storage is less than or equal to the total amount of data being stored. In case 1. items stored will take some time to leak out of the network. In case 2. an objects lifetime will be very short. I suspect that freenet has been operating mostly in the second arena. I don't know if anyone has attempted to model this but it seems to me that because of redundancy (both due to the data "sticking" to nodes as it passes along and due to actively introduced redundancy) the actual ratio of data desired to be stored to total freenet store would have to be much greater than one to one. Given scenario 1. I don't think you would have to "refresh" your data by retrival very often. However scenario 2. means that you are basically competing with others for data store. A local means of minimizing this is to ensure you have a sufficiently large local store (as I mentioned above). If I have 100 megs of stuff to insert I want to have (guessing here) 200-300 meg minimum of local freenet space. I don't think anything I've said here is new or a suprise to anyone but I think there are a couple things that come out of this. First, there is already redundancy in the system - adding more may cause more harm than good. Secondly, periodically retrieving files is probably a valid way to keep them in the the network. ______ FYI in my limited experiments I was able to keep 50 meg or so available. I did a pulldown of the files using a script and ran it at 5 minutes, then a few hours, then a day or two, then several days. I am waiting for freenet to get a little more stable before trying again. I would like to write a perl script that inserts the files and puts them into queues for periodic retrieval. ______________________ Matt -- ___________________ > freenet-tech mailing list > [EMAIL PROTECTED] > http://lists.freenetproject.org/mailman/listinfo/tech _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
