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. > 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. Scott Young _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
