On Thursday 21 January 2010 14:51:53 alex wrote: > 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.
IMHO a naive insert on demand system could be comprehensively spammed pretty easily. To what degree WoT can prevent this I dunno, maybe it can solve the problem. > > 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. Which they may well be, but WoT may be able to prevent this. > > 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?). Well, try it. But yes we compress everything unless you tell the node not to. And most of the time that saves time, if not for the inserter than for the requesters - and probably for both. Because inserting is slow, and most files can gain a few percent even if they are already compressed (e.g. video). > > 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. There is no need for it to cost much user time management, if the client is good. > > >> > 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. That's what we're working towards... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100121/ff7317b9/attachment.pgp>
