On Friday 16 January 2009 20:43, Volodya wrote: > 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.
The difference is actually doing the request brings the data into the store, and takes bandwidth on the part of the attacker. Admittedly they can cancel the transfer, but probing is bad.
pgpsmpIv8Mvrs.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
