Matthew Toseland wrote: > On Wednesday 20 January 2010 16:25:18 alex wrote: >> Matthew Toseland wrote: >> >> > On Wednesday 20 January 2010 10:37:12 alex wrote: >> >> Matthew Toseland wrote:
(snip other points taken) >> > 3) DoS issues. How do you prevent bogus >> > requests for data in an automated insert on demand system? Maybe WoT >> > will help, but it's early days. >> >> Well, the worst that may happen is that you get requests for everything >> you have, and then you're at the scenario where you point to in 4). > > Right. In which case what was the point in the first place? I think the advantage, is that, as long as spamming has to be targeted (i.e. /they/ cannot spam the whole system cheaply, but have to target /your index/ in order to request everything), 99% of the users won't have to insert everything upfront. Compare a situation where you mark for sharing lots of files and do not insert anything, until some legit request arrives, with another in which you start inserting GB of data just in case. I know there are possible objections to sharing huge libraries, either in terms of files or of size. Also the security weaknesses of insertion on demand. I don't want to digress. >> >> However, since a node has a maximum insertion rate, I don't see here a >> big issue, as long as insertion priorities are working. > > The point is that DoS attacks make insert on demand pointless. As per above, I think this is true only if the majority of requests are spam. I'm remembering my attempts at inserting large amounts of data (~1GB) in not-so-large files (one year ago or so), when the node choked while calculating the hashes, not even starting to insert; that was a pain, and while the root problem was that the node wasn't working as expected (processing speed was dropping *not* linearly with the number of insertions, and some got stuck and never completed hashing[1]), it would be great to be able to say to people: "You don't need to insert your multi-GB stuff in advance". I haven't tried again in recent time a similar insertion pattern... getting curious about it right now. ([1] I say hashing but that wasn't the term used by the thaw interface. Compressing perhaps?). In the end, I agree that this is a somewhat minor point if everything is working as expected. However, historically, insertion has been a demanding process on machine resources and user time management, when done manually. Both frost and freemulet used insertion on demand, which hints at a desire to both minimize and automatize the insertion process. >> >> > 4) Capacity. IMHO if Freenet is working well we >> > should not need insert on demand: Its capacity should be much greater >> > than it is now, and we should be able to just insert and fetch the >> > data. >> >> In this regard, there's an advantage about on-demand insertion, which is >> that perhaps you'll end never inserting a huge part of your shared files. >> Given the time it takes for insertion, I see this as one of the biggest >> gains. > > Maybe. But if you did insert it it would be accessible immediately to > people who click the file - if Freenet is working. That would be ideal, for sure. _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
