On Tuesday 29 July 2003 05:28 pm, Scott Young wrote: > On Tue, 2003-07-29 at 14:47, Tom Kaitchuck wrote: > > On Tuesday 29 July 2003 12:22 pm, Tracy R Reed wrote: > > > On Tue, Jul 29, 2003 at 12:04:13PM -0500, Tom Kaitchuck spake thusly: > > > > That is all well and good, however it does not give us any way of > > > > insuring that nodes that have a fast connection to each other on the > > > > underlying network will be any more likely to share a similar > > > > specialization. I can > > > > > > Won't the fact that they prefer to route through each other cause > > > similar data to pass through these nodes making their specializations > > > converge? > > > > Yes, but only to a much lesser extent. If you contact a node, you may > > know it's fast. However you don't know how fast it is to you relative to > > anyone else. So all nodes that are fast for you receive more of your > > traffic. However you are going to drop any connection that is not > > particularly usefull. So if two nodes have a fast connection to each > > other, but have very different specializations, the only requests that > > would be routed there would likely have a very high HTL. This means that > > you would be more likely to drop it's connection before it significantly > > affected your datastore. > > Remember that specialization is not just having a dense area in your > DataStore. Specialization also means (in NGR terms) that your node > knows a fast route to a specific area of the keyspace, AND other nodes > know you can get them the data fast. So if your node specialazes in > 0x3E1... and another node on the same LAN as you specializes in 0xEB3... > (and your node is connected to this node on your lan), then to the > outside it would look like your node specializes in BOTH areas, because > you can route to the data in both areas quickly.
Yes. That is true. However we are still doing little to maintain open connections to, and cache data, that is close to data that we already have. One way to do this is to modify what we are storing, another is to have a better way to select what to cache, and who to open connections to. Having both would be best, but mealy dropping the last used data or connection is not cutting it. Right now Freenet certainly doesn't live up to the promise of routing in log(M)/Log(N) hops. (M is total nodes, N is connections) In fact right now it is routing little better than a Binary Search Tree. NGrouting will improve speed but it won't decrease hops. > > One solution would be to weight the speed of the outgoing transfer when > > considering what data to remove from your store. For example if you cache > > all incoming data, and then when you need to decide to get rid of some > > data, you use some function that looks at each piece of data, and does a > > weighted average of the of the total transfer rate of the data in that > > aria. Then drop the point with the lowest value. > > > > IE: If you want to determine a value for index #3, do something like: > > > > 1/2 * average KBps of transfer #1 of index #1. + > > 1 * ( average KBps of transfer #1 of index #2 + average KBps of transfer > > #2 of index #2) + > > 2 * (average KBps of transfer #1 of index #3 + average KBps of transfer > > #2 of index #3 ) + > > 1 * average KBps of transfer #1 of index #4. + > > 1/2 * ( average KBps of transfer #1 of index #5 + average KBps of > > transfer #5 of index #5 + average KBps of transfer #3 index #5) > > > > This would make fast connections perseption of your store more important, > > as presumably you can transfer more data through them in the future. > > Comments? _______________________________________________ > > It would be much simpler to use the file size as a variable for the the > routing and data deletion algorithms to learn with. If a node is faster > at getting large files to you, that probably correlates to that node > having more bandwidth. If your node gets fewer requests for large files > (i.e. you're on dialup and other nodes don't like to download large > files from you), large files can be deleted to make more efficient use > of your DataStore. > > The transfer speed is a very sketchy variable to use, and it doesn't > even need to be mixed in with the equation. File size is much more > precise. Knowing the size would help routing, but what exactly do you propose for the data store? _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
