On 2010/11/06 (Nov), at 8:44 AM, Matthew Toseland wrote:
Then perhaps someone else would like to review the code. It is a *very* short patch (+18-2; incl. many blanks and comments).
If it were not enough that I have *already* done that, and if it were not enough that I wrote a simulator anyone can run that demonstrates that, then perhaps you would accept the output of my simulator run??? ----simulator output---- 4 : seeds: 1, connected: 1 opennet peers: 0, connected: 0 Announcement to 127.0.0.1:8007 starting... 5 : seeds: 1, connected: 1 opennet peers: 0, connected: 0 [...snip...] 15 : seeds: 1, connected: 1 opennet peers: 0, connected: 0 Announcement to 127.0.0.1:8007 added node 127.0.0.1:8022. Announcement to 127.0.0.1:8007 added node 127.0.0.1:8021. Announcement to 127.0.0.1:8007 added node 127.0.0.1:8020. Announcement to 127.0.0.1:8007 added node 127.0.0.1:8019. 16 : seeds: 1, connected: 1 opennet peers: 4, connected: 3 Completed bootstrap (3 peers) in 32231ms (32s) Announcement to 127.0.0.1:8007 added node 127.0.0.1:8018. Announcement to 127.0.0.1:8007 added node 127.0.0.1:8017. 17 : seeds: 1, connected: 1 opennet peers: 6, connected: 6 18 : seeds: 1, connected: 1 opennet peers: 6, connected: 6 ------end simulator output------ The node are strung together 8007(seed), 8008, 8009, 8010...8021, 8022. What this output shows is that from one announcement (to the only simulated seed node), the previously-unconnected peer acquired 6 connections (the max as defined and tunable in the patch) from twenty chained nodes *deepest-first*... ***IT WORKS***
It does work, period. I am sorry that (at the moment) you cannot see *how* it works, but you'll just have to accept the fact that *IT DOES*. I would like to think that this patch is particularly readable and easy to understand, so I will presume that the real matter is that you presently do not have *time* to understand it for yourself.
That is totally not the point, and missing the larger picture. Let's try for some objectivity here: THEORIZED to accept a good mix of a few long links and many short links (by toad) THEORIZED to be very destructive to routing (by me) IN PRACTICE works "good enough" (provided grace periods keep seed-nodes connected to network at-large, etc). IN PRACTICE does not scale because it always tries to connect to *ALL* nodes between the seed nodes and peripheria Depth-first THEORIZED to provide many good short network links at a very-routable location (absent my earlier path-folding point #2) THEORIZED to relieve the network churn around the seed nodes (and therefore possibly a degree of load) THEORIZED to improve the routability of the network around the seed node by the principal of destination sampling IN PRACTICE does scale because it returns a fixed maximum nodes (some distance from the seed nodes) IN PRACTICE is guaranteed to be no-worse-than shallow-first, because shallower nodes will return there refs if needed Is there really even a choice? Shallow-first is horribly broken! -- Robert Hailey (updated/final patch attached for your further convenience) |
depth-first-announcement2.patch
Description: Binary data
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
