On Jan 15, 2009, at 8:09 AM, Matthew Toseland wrote: > We have several conflicting goals here: > - Minimise request latency for fproxy. > - Maximise the probability of a request succeeding. > - Maximise throughput for large downloads. > - Use all available upstream bandwidth. > - Don't break routing by causing widespread backoff.
On Jan 14, 2009, at 7:57 AM, Matthew Toseland wrote: > IMHO the system is over-optimised for throughput at the moment. Let's assume that the current system works great for throughput, and all we want is to put very-low-latency in the mix w/o much headache. Consider this... a CHKPreRequest. Without actually asking one of our peers for the data, we simultaneously ask them "how long would it take?" and reserve the 'slot'. While still having it 'reserved' we can then query other nodes and pick the fastest route, decline the others. IMHO this would still need a mechanism to transfer one chk at a time over a given link (strict priority) to actually optimize latency. -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090115/f389bebf/attachment.html>
