On Sat, 2003-04-05 at 03:58, [EMAIL PROTECTED] wrote: > >This is a great idea, but I see one problem. What if a malicious node > >just responds quickly but "trickles" the data at something like 10 > >bytes/minute? Should transfer speed also be taken into consideration > >with this algorithm? I could see a node serving up dozens of > >connections over a dialup link because of low latency (even though the > >bandwidth is low), while a satellite broadband user would be more latent > >but get the actual data to the node quicker. A low-latency 0.5 k/sec > >connection would get you a 1 MB SplitFile block much slower than a > >high-latency 10k/sec connection. > > what about basic pcache not on "first response time" (latency) but on "transfer > speed" (ticker started when key is requested and stopped when the last byte of > the requested key is tranferred, resulting into a bytes/sec value, just like on the > splitfile information pane) ? > in fact, everything what's important is the time needed to have this key on our > side, not the latency or other things, so it would make sense to actually respect > that value ;) > >
The tricky part is that there are 32KB files mixed in with 1 MB files along the keyspace. Mixing results from different file sizes screw up the RTE vectors because 1 MB files take significantly longer to download than 32 KB files. One solution might be making the RTE vectors 3 dimensional with the file size as the third dimension. Scott Young _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
