On Thursday 15 January 2009 17:22, Robert Hailey wrote: > > 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.
Why would we want to route the request to a node that isn't optimal for the key? And anything that probes for the existence of a key obviously is bad. > > IMHO this would still need a mechanism to transfer one chk at a time > over a given link (strict priority) to actually optimize latency. Then we would have to queue them. Queueing or multiplexing, either way you end up with latency. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090115/985d61be/attachment.pgp>
