On Thursday 29 Mar 2012 05:36:42 Steve Dougherty wrote: > Hello, > > I was hoping to get some feedback on my Google Summer of Code > application. I've noticed that the lack of detailed information > available on network topology, link distribution, and overall makeup > and health makes it difficult to make decisions on how to improve > network performance. To that end, I'd like to: > > -Clean up the existing probe code: document, improve readability, and > correct errors and annoyances. To name some examples: > -Peer locations are reported as doubles with known/unknown, backed > off/not backed off encoded into the value, and there are some > ambiguities in these values. I'd like to make a Location class > instead with separate reported fields. > -Probe traces can still be returned after a completion message; > waiting a while for more traces could be nice. > -Make probes available over FCP: > -Document along with other FCP messages. [0] > -I've already started initial implementations of these changes in > Fred [1] and lib-pyFreenet. [2] > -Plot network attributes revealed through probe requests: > -Node churn > -Network size > -Link length distribution > -Graphs of topology: Gephi [3] could be useful here. > -I've already started an initial implementation of such a tool. [4] > -Implement the probes and traces described in bugs #3568 [5] and #3550 > [6]. I don't have experience adding new message types to Fred - I've > only registered a message type from a plugin [7], so I'm not sure what > it involves or if it's within the scope of a summer. I'd appreciate > anyone's thoughts on this. > > Is anyone willing to mentor me on this project? > > Thanks, > Steve Dougherty
I don't know whether this should be GSoC or not, and I don't think I have time to mentor this year. However, there are basic issues with probe requests: I don't think that building more stuff on top of probe requests is a good idea. IMHO we need to get rid of probe requests as they are now. Partly for security reasons (they give away way more info than is needed, and they give away too much of it at once, in too targeted a way; I don't think we need to be able to probe specific nooks and crannies of the keyspace at this point, because IMHO the problems are more general). Although, I'm not sure what exactly we need in the New Random Routed Probe Requests. For some purposes (tag-and-release-style stats on total nodes, (optional) random sample stats on things like datastore size, checking retrievability of a block), it's straightforward and obvious. But if you are gathering stats on link lengths, what do you need? Do you need a full list? Do you need to know backoffs? Do you just need a computed value? What about churn? I guess we could keep the current probe requests if there's a good reason to do so ...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
