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.
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. 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
