Also I don't think anyone has agreed to mentor this project. Can somebody let me know if there is a mentor?
Thanks On Tue, Mar 27, 2012 at 4:46 PM, Chetan Hosmani <chetanhosmanigsoc at gmail.com> wrote: > Thanks for the advice, I think I will find this very necessary if I > get to work on it. It will speed up the process too. > > On Tue, Mar 27, 2012 at 3:10 PM, Ximin Luo <infinity0 at gmx.com> wrote: >> One word of advice: if you find the code hard to understand, it is not >> necessarily your fault. IMO the codebase is messy atm. If you have trouble >> with >> any file, use "git log <path/to/file>" to find the previous people that >> worked >> on it and go bug them to explain it to you in more human terms. They deserve >> it :p >> >> X >> >> On 27/03/12 10:21, Chetan Hosmani wrote: >>> Hello, >>> >>> I have been idling ?on the IRC channel for quite some time now. The >>> response from freenet is really good. >>> >>> For my GSoC application I have been working on a proposal for the >>> transport plugin. Although the response from freenet is "this is a >>> very hard project", I have tried my best to understand the codebase of >>> freenet and the exact purpose of this project. In particular I have >>> spoken to Arnebab, toad_ and nextgens regarding this assignment and >>> from them have gained a good insight on what needs to be done. >>> >>> Based on their information and some research on the project this is my >>> present standing. Some of it might still be incorrect. >>> >>> Firstly Freenet presently runs extensively on UDP based sockets. The >>> communication happens at several layers and with different mechanisms >>> i.e sockets, streams, reliable packets, UDP, so on... The major >>> problem is that the code has been integrated very tightly. For e.g. >>> NodeCrypto class uses only UDPSocketHandler for communication. So this >>> means that the data cryptography and communication at the transport >>> layer (using UDP in this case) are grouped very tightly. >>> >>> This means that a major refactoring of the code is needed. This task >>> is supposed to be the hard part (where prior freenet experience is >>> needed). >>> Changes will definitely encompass refactoring - Node, NodeCrpyto, >>> UdpSocketHandler and other related dependencies. >>> For this I plan to do a very thorough research and practice on the >>> core functionality of freenet way before the coding period begins, so >>> I know the exact task at hand. >>> I ll obviously be at the mercy of the community. >>> >>> On the other hand a lot of work has been completed. For eg. >>> implementations of OutgoingPacketMangler and IncomingPacketFIlter >>> allow packets defined for any transport protocol. This is also >>> mentioned here - "Last year's work on new packet format should really >>> help although some transports (really small packets e.g. pretending to >>> be Skype) will still need to do their own splitting/reassembly (this >>> should probably happen within the node too, although it should be >>> possible to turn it off). " >>> Streams have better support: >>> https://bugs.freenetproject.org/view.php?id=2214 >>> >>> Secondly once this is achieved, UDP will become an individual >>> transport plugin and similarly the framework will support users to >>> write their own transport plugin. Now this means the cryptography and >>> packet modifications are done in a different level, and hence the >>> developer need not bother about them. As part of the GSoC project I >>> will be required to make this change and also in the process develop >>> TCP transport plugin. >>> Here I think I am more comfortable, and I think my existing knowledge >>> of sockets should get me through. >>> >>> Thirdly, some other objectives as toad_ mentioned as important, >>> include ways to deal with having multiple connections open to the same >>> peer at the same time. Presently haven't thought about this, and don't >>> know that much about freenet for the exact need for this. >>> >>> And apart from this (some confusion regarding this) is implementation >>> of other application level protocols like HTTP, VoIP and so on. Now >>> this can "become" easy if protocols like TCP are enabled. Also as >>> mentioned in the project page is the ability for communications to >>> pretend to be of other protocols. Again I believe it means that an >>> example plugin needs to be developed. >>> This part of the project would spill outside the deadline but it can >>> get direct contribution from the community. >>> >>> The application period has now started, so I ll be turning in mine. >>> But I was hoping I could clarify a few things. >>> >>> I know this is beyond what can be finished in three months. *Please >>> give me your opinion on this proposal and what I should do. * >>> >>> Also as nextgens mentioned, this project would be very hard for me, I >>> would like to know if I should continue researching more or probably >>> give something else a shot. I still have a week to go either way. But >>> I am aware this requires a lot of effort and knowledge and I am ready >>> for that. For now I will try and fix a bug. >>> >>> Thank you >>> >>> PS: Comments, including "you don't know shit" or "go watch TV" are welcome >>> :) >>> _______________________________________________ >>> Devl mailing list >>> Devl at freenetproject.org >>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >> >> >> -- >> GPG: 4096R/5FBBDBCE >> https://github.com/infinity0 >> https://bitbucket.org/infinity0 >> https://launchpad.net/~infinity0 >> >> >> _______________________________________________ >> Devl mailing list >> Devl at freenetproject.org >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
