Robert Hailey wrote:
>
> 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.
I think toad_ is talking about privacy considerations here. Somebody can use
this to prove the datastore of a sigle peer. However, i don't understand what
is
the different between this and actually requesting the data and measuring the
time yourself for the attacker. If there isn't any difference then there is no
*extra* problem.
- Volodya
--
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast
http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal
http://www.freedomporn.org/ Freedom Porn, anarchist and activist smut
"None of us are free until all of us are free." ~ Mihail Bakunin
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
