On Friday 15 October 2010 14:40:06 Matthew Toseland wrote: > The next step, after Monday, assuming that 1292 works, will be to deploy > fairness in accepting requests between peers. This will greatly reduce the > possibility for denial of service attacks, and make requests from slower > nodes more likely to be accepted.
1293 and 1294 make essential fixes to the block transfer code. 1295 will include some further changes, removing some cruft and reducing the maximum time between blocks from 2 minutes to 30 seconds. 1296 will deploy the fairness code, which could be disruptive (especially as I will probably include the changes to load calculation, although I might split that out for 1297 instead), but should result in improved performance after a few days. After that, the next build (1297 or 1298) will merge a bunch of fixes and optimisations that are currently in master. Then... > > After that, we will probably deploy the bulk vs realtime flag. This is a > somewhat larger change. It requires the threadless block transfers code as > there will be a significantly larger number of bulk requests running than the > total number of requests running now. It is required for the next stage > because of latency issues. It essentially means setting a flag to indicate > whether a request wants low latency or high throughput, and treating the two > groups separately. Persistent downloads will normally be high throughput; web > interface stuff will normally be low latency. It should improve performance > for both. It could be disruptive and affects a fair amount of code. > > After that, the next step is to tell each node what our current capacity is > for requests from them. This will allow the node to limit the number of > requests that it sends us rather than repeatedly sending and getting its > requests rejected. A related issue is two-level timeouts, which help us to accurately track how many requests are running on the next node by determining whether it is the cause of a timeout. > Once this is deployed, I can finish implementing and debugging the new load > management mechanism, which eliminates originator-side load management, is > much less vulnerable to denial of service attacks, and allows us to eliminate > misrouting except in cases of nodes being severely overloaded. This in turn > should significantly improve bulk throughput, darknet performance, routing > accuracy (in the sense of data being stored where it should be), and hence > data persistence and general performance. It could take a while to finish > this although it is largely already implemented. It does affect several areas > of the code e.g. we need an accurate count of how many of our requests are > running on our peer. > > Once there are no further disruptive changes from load management, we should > deploy zidel's new packet format. This will make it possible to run Freenet > on a wider range of connections, pave the way for future work on transport > plugins, but most importantly substantially improve the efficiency of the > link layer - the "payload percentage". > > These are all of the network level potentially disruptive changes that I > believe are reasonable prior to 0.8.0. However IMHO they are probably worth > it, especially given the substantial progress already made.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
