Discussion pertaining to the next release of Freenet.

Chetan Hosmani | 11 Jun 2012 20:34

Transport Plugins Update (GSoC)

Hello everyone,

I am sorry I have had some Internet connectivity issues over the last
week and haven't been able to post updates. nextgens and toad were
busy too, so I haven't been able to discuss anything much with them.

However I have managed to push a decent bit of code. Although the
speed will increase, now that my vacation here begins (semester ended
late).

Here is an overview of the progress made since I began working on the project.

Current status-
1. Basic plugin architecture is complete for packets and streams
2. Design(code) to register a plugin is complete -
	a) Now I can start working on a plugin too. All the design
requirements are complete.
	b) Notifying various components of fred about a new transport plugin
registering is almost complete.
3. Refactoring code is midway. This has been a bit slow due to my
mentor and toad being busy; and it being my end semester period.
Things should move fast now that my semester is over.
	a) Currently working on handling the setup, and having separate
session keys and mangler object for each transport.
	b) Working on the Peer (detectedPeer/nominalPeer/remoteDetectedPeer
fields) object, as this will be different for each transport. Usually
only the port number will differ. But we might have plugins supporting
non-ip based transports in the future.

My main aim till now has been to finish as much as possible of the

(Continue reading)

headers

Steve Dougherty | 12 Jun 2012 06:34

Re: Transport Plugins Update (GSoC)

On 06/11/2012 02:34 PM, Chetan Hosmani wrote:
> However I have managed to push a decent bit of code. Although the 
> speed will increase, now that my vacation here begins (semester
> ended late).

I'm glad to hear things are going well so far, and that your Internet
connectivity issues and available time should improve shortly.

> 5. Write a PoC steno plugin.
> 
> I am also in parallel implementing as much as possible of stream 
> transport API.

Do you anticipate that your work will include a proof of concept
stream transport? (Would the stenography plugin use the stream API?)
Is my understanding correct that stream transports could do something
like disguise Freenet traffic as HTTP?

headers

Chetan Hosmani | 12 Jun 2012 18:13

Re: Transport Plugins Update (GSoC)

Thank you. I hope to complete as much as possible within the time frame.
I definitely have a lot of goals after GSoC as well.

Yes of course, I need to have a PoC stream plugin, to design the
framework. They will happen in parallel.

An HTTP steno plugin is mostly post GSoC, but I think a lot of people
have a lot of ideas (I was told), and might want to make their own
plugins. But again I will work on a Proof of Concept plugin there as
well.

One more issue with an HTTP plugin for those behind firewalls, is that
it can't accept/listen to connections always. So I suppose we ll have
to address that too, as we have no central server. From what I see the
one behind a restrictive firewall will definitely have several issues.
But that is expected.

> On 06/11/2012 02:34 PM, Chetan Hosmani wrote:
>> However I have managed to push a decent bit of code. Although the
>> speed will increase, now that my vacation here begins (semester
>> ended late).
>
> I'm glad to hear things are going well so far, and that your Internet
> connectivity issues and available time should improve shortly.
>
>> 5. Write a PoC steno plugin.
>>
>> I am also in parallel implementing as much as possible of stream
>> transport API.
>

(Continue reading)

headers

Matthew Toseland | 19 Jun 2012 22:02

HTTP plugins was Re: Transport Plugins Update (GSoC)

On Tuesday 12 Jun 2012 17:13:53 Chetan Hosmani wrote:
> Thank you. I hope to complete as much as possible within the time frame.
> I definitely have a lot of goals after GSoC as well.
> 
> Yes of course, I need to have a PoC stream plugin, to design the
> framework. They will happen in parallel.
> 
> An HTTP steno plugin is mostly post GSoC, but I think a lot of people
> have a lot of ideas (I was told), and might want to make their own
> plugins. But again I will work on a Proof of Concept plugin there as
> well.
> 
> One more issue with an HTTP plugin for those behind firewalls, is that
> it can't accept/listen to connections always. So I suppose we ll have
> to address that too, as we have no central server. From what I see the
> one behind a restrictive firewall will definitely have several issues.
> But that is expected.

A future HTTP plugin project:
1. Implement and use PortManager, so that TCP-based plugins get forwarded automatically if possible by UPnP.
- If chetan_ has time, he could implement this. I don't expect any of the rest.
2. Enable an HTTP-based plugin by default on most nodes.

Some interesting aspects of HTTP plugins:
- They can get through proxies in many cases, and support for explicit proxying should be configurable.
- The CONNECT command is supported by some of those proxies, which provides an easy and efficient way to just
get a raw stream.
- Similarly, if we don't worry about proxies, we can pass-through to a real HTTP server (on another
port/computer) until we see a magic word (computed from e.g. the time, a key in the noderef, etc).
- If we do have to speak actual HTTP, there are many ways to abuse the protocol, and many latency tradeoffs. We

(Continue reading)