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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
