[freenet-dev] GSOC 2012 Tansport Plugin
On Tuesday 27 Mar 2012 10:21:58 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 :) Okay, major issues: Re crypto, we need two (or more) separate APIs that a transport plugin can register itself with, the obvious ones at this point being: - Streams. - Unreliable packets. Each of these transport types will need: - Crypto - both setting up the connection and once it is connected. - Authentication. - Bottom part of the retransmission logic. (Probably not needed for streams). - Code to actually drive the transports. (For a packet-based transport, we probably expect the plugin to provide its own send/receive loops; for a stream-based transport we'd probably want it to give us an InputStream/OutputStream pair for each connection) Some of this co
Re: [freenet-dev] GSOC 2012 Tansport Plugin
On Tuesday 27 Mar 2012 10:21:58 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 :) Okay, major issues: Re crypto, we need two (or more) separate APIs that a transport plugin can register itself with, the obvious ones at this point being: - Streams. - Unreliable packets. Each of these transport types will need: - Crypto - both setting up the connection and once it is connected. - Authentication. - Bottom part of the retransmission logic. (Probably not needed for streams). - Code to actually drive the transports. (For a packet-based transport, we probably expect the plugin to provide its own send/receive loops; for a stream-based transport we'd probably want it to give us an InputStream/OutputStream pair for each connection) Some of this co
[freenet-dev] GSOC 2012 Tansport Plugin
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 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 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 " 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
[freenet-dev] GSOC 2012 Tansport Plugin
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 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 " 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.freen
[freenet-dev] GSOC 2012 Tansport Plugin
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 :)
[freenet-dev] GSOC 2012 Tansport Plugin
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 " 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 -- next part -- A non-text attachment was scrubbed... Name: signature.asc T
Re: [freenet-dev] GSOC 2012 Tansport Plugin
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 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 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 " 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
Re: [freenet-dev] GSOC 2012 Tansport Plugin
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 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 " 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@freenetproject.org >> https://emu.freenetp
Re: [freenet-dev] GSOC 2012 Tansport Plugin
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 " 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@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 signature.asc Description: OpenPGP digital signature ___
[freenet-dev] GSOC 2012 Tansport Plugin
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@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
