Oskar wrote
>
> This has nothing to do with weighing by connection - your simply saying it
> will be faster because the data ends up in more places, which is
> completely contrary to the smart routing we are trying to achieve.
No, it is not about storing data in more places I can imagine using an
unrequest feature to stop the losing path from actually caching the data
(or a commit to the winnig path) although I'm not sure its worth it.
Its not that the data gets stored in more locations just in better locations
and the fact that a particular route can deliver it quicker proves to me
that
it is better you are right its not about weighing the connection its about
weighing
the total performance of a given node/route.
It is at least as good as the current aproach since it uses the same
criteria to select the nodes.
>
> Obviously you would have it so that if two branches reached the same node
> one after the other the latter would simply be dropped, since it can't
> possibly win the race (unless you are doing the forking just to put data
> in more places which is silly and dumb). Trying to bounce the later fork
> back would be ridiculous since it would it's "forced" route of being
> pushed off where it naturally wants to go (because the faster fork got
> there first) would keep trying to converge with the natural route (doing
> no good and causing lots of work for the nodes).
>
I don't think it is that obvious that the slower branch can not win the race
but you're probably right.
If a quickest branch gets stuck in some local maximum the slower one could
end up finding the data
sooner but I'm not sure this is desirable behaviour.
Neil
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
