On Monday 03 December 2007 20:09, Robert Hailey wrote: > > On Dec 1, 2007, at 6:02 PM, Matthew Toseland wrote: > > > On Friday 30 November 2007 23:03, Robert Hailey wrote: > >> > >> To illustrate my point the following patch shows an approximate 100% > >> speedup for freenet, by my crude profiling. > > > > Speedup measured how? More comments below. > > Measured in average time to handle a request (i.e. the realRun()-time > of RequestHandler), which I reason is proportional to the time it > takes for a request at-large (propagating through the network).
Not necessarily, but it looks like the Accepted round-trip is a big part of the total request time yeah. *Very* nice catch! > > > One reason to keep it as-is is to deal with nodes connecting, > > sending a load > > of requests, and then disconnecting, as a DoS attack. This is > > implausible as > > a sensible the load limiting system won't let them start enough > > requests to > > be a problem given the relative difficulty of getting new > > connections. Of > > course, getting new connections is likely to be rather easy on > > opennet... > > I agree. Although, whereas sendSync() waits up to one minute for the > given request to clear the queue, this attack would be available > presently... only offset by a constant amount of time. Well, without the sendSync(), the attacker doesn't have to ack the packet, which saves him some bandwidth. > And the > attacker would have to accept enough packets to make the node believe > you are 'connected'. Okay, on further research... If an attacker connects to a node and starts sending requests, he can stay connected forever simply by keeping on sending packets. He can quickly gag the node simply by never acknowledging any packet, but the node will continue to accept and propagate his requests subject to global limits. Furthermore, the node will leak memory: all the packets that would have been sent to the attacker get queued in RAM. Eventually the node will OOM, and be restarted by the wrapper. Once it loads back up, it will start accepting requests all over again. Ouch. Fixed (or greatly ameliorated) in trunk by amongst other things rejecting requests when the queue to the node is over 4MB, or when it would take over 10 minutes to transfer at current throttle rates. With that fix, the attack we were talking about is very much reduced. > > > Another reason is if a node or a link is hopelessly overloaded, we > > don't want > > to run a request which will not serve any purpose because the node > > will > > timeout on us and route it to another node. This isn't really dealt > > with by > > the current code either. > > I'm not sure I understand your point, but (not being a point of > contention) you don't have to explain it. It seems to me that this > would HELP overloaded nodes, as we process their requests without > waiting for the ack which is a mile down there send queue; they might > actually get there data (once it arrives and makes it to the front of > the send queue). If a request comes in, and the node which sent the request is so hopelessly overloaded that it will miss our Accepted and timeout on us, and send it to another node, then it's not very useful to do the request. Actually that's not true: if it goes to another node, it will get coalesced, or it will get the data that we would have sent to it. So it's not a big deal. > > > So it looks like your patch is worthwhile... > > > > You can use the same logic on all the Handler's and Sender's. Either > > send me a > > new patch, or send me your preferred username, password and email > > address so > > I can give you an SVN account and you can commit it yourself. > > Can do. I look forward to your commit! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071203/f3b567d4/attachment.pgp>
