On Jan 15, 2009, at 4:47 PM, Matthew Toseland wrote: > On Thursday 15 January 2009 17:22, Robert Hailey wrote: >> >> 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.
Forgive my ignorance, but why is any kind of probing obviously bad? My whole point is that we probe (maybe two or three) peers to find out the optimal path, and pick the one with the least latency for a realtime request. If a node receives such a request, and it has it in it's datastore, the latency is transfer time, otherwise it is the (best) downstream time plus transfer time. In either case you add to the time-claim that time expected to finish other realtime requests queued in front of it. >> 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. Correct, but if each node is obeying the above algorithm the queue length is taken into account. The queue is kept small by reservations being 'cancelled' once the optimal path is chosen; and playing nice could be enforced by maximum reservation times and penalties for providing inaccurate transfer time estimation. What's more, there is a great way to handle multipaths! As we can remember our chosen latency required to get the data ourselves (our downstream queries), and answer several upstream reservations for the same id based on that value (closing it only after a semaphore-ish counter drops to zero). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090116/a8555a5a/attachment.html>
