On Fri, Apr 21, 2006 at 05:22:31PM +0000, Thomas Bruderer wrote: > > > There seems to be the missleading concept that inserts have to be slower > > > than > > > downloads. The argument is: it needs to go over more hops therefore it is > > > slower. I have discussed this issue, and I think its obvious that this is > > > not > > > true... > > > > > > > > You are only considering the local cost. Because an insert visits 20 > > nodes instead of 7, it will hit 3 times as many nodes. This does not > > just affect latency! It affects throughput, for the simple reason that > > an insert causes 3 times as much load on the network. Therefore we can > > only send 1/3rd as many inserts as requests. > > but I am sure we agree that each block is most likely requested more than only > three times? I am sure the global share of bandwith is dominated with > downloads > and not with inserts, So deven if our inserts use more bandwith than a > download > once. The global balance is probably not influenced by inserts.
So what? > > I see we cant prioritize inserts too much, because malicous flooding would be > a > problem then. But what about a prioritzing upto 1/3 of the whole bandwith? Right now we do prioritize them: We use a single window for both requests and inserts. This may be a bad thing. The practical result is that we send more inserts than are strictly justified by the number of rejections we get. > > Well First of all we have to see if the Bugfix is a solution. If I get 1/3 of > my > bandwith for my inserts which would be 10K then, would be a major step onward, > and after that we could move to other things ;) I'm not sure how we would do that, or if it would be a good idea. I don't think it's unreasonable to expect inserts to be 3 times slower than requests on a real network. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060421/d9ab53e2/attachment.pgp>
