[freenet-dev] Transport Plugins Update

[Matthew Toseland]

On Wednesday 23 May 2012 18:00:40 Chetan Hosmani wrote:
> Hello everyone,
> 
> I have been a bit busy last week, and haven't committed much code.
> Here are the following refactor changes I have implemented and pushed
> to "refactor-1" branch-
> 
> 1. Added a separate list for transport managers. So we basically have
> a list which will contain a manager for every mode. Presently it has
> two - opennet and darknet.
> 
> 2. NodeCrypto functions in the following way-
> a. Transport managers are created in the node irrespective of whether
> opennet or darknet is running.
> b. NodeCrypto on creation for every mode accesses its respective
> transport manager to get a list of transports.
> c. It runs the method handleNewTransport to initialise a PacketMangler
> and handle each transport plugin.
> d. If the list of transports is empty, then it will function using the
> inherent UDPSocketHandler transport and run normally.
> d. When a plugin is loaded (on registering with TransportManager), the
> manager checks if the corresponding mode (opennet/darknet) exists and
> notifies the NodeCrypto by calling the handleNewTransport method.
> 
> 3. UDPSocketHandler now extends PacketTransportPlugin, and I have made
> changes so that it looks like a plugin. I have built it and checked.
> It runs fine.
> It also registers in the transport manager.
> 
> 4. Presently working on replacing the Session keys in the PeerNode
> object. There are three - current, previous and unverified. I am not
> yet well acquainted how these work.
> But the idea is to have a separate connection object PeerConnection that -
> a. Has a unique PeerNode
> b. Has a transport associated
> c. Has the corresponding Peer (detected Peer) object associated
> (different transports are on different ports, and we can keep it open
> to use different addresses itself)

This should be fairly similar to the current code. There are some complexities, 
e.g. : is not necessarily valid 
externally; this is why we include both that and the address/port that our 
peers tell us is our address/port number.

> d. A list of session keys. It need not be three. The code can become
> more generic.
> 
> So PeerNode has a list of PeerConnection objects, for every active
> transport. The PeerNode will decide the transport to use using these
> objects.

The rest looks good.
> 
> 
> The official coding period has started. So after a few more additions
> I will merge them to "Transports" branch and begin working on a new
> branch "PacketTransports".
> Also awaiting some code review, after nextgens becomes free.
> 
> For the coming week-
> 
> 1. Work and finish handleNewTransport
> 2. Finish the PeerConnection object
> 3. List the changes needed for multiple transport support in PeerNode
> (implementing PeerConnection list)
> 4. Figure out PeerNode code to use different transports
> 
> Later on I will mainly work on NewPacketFormat which needs to be
> changed so that they are more generic for Packet Transports. Hope to
> have toad's and zidel's help then.
> 
> ArneBab - Flog is coming too. Sorry :)
> 
> Regards,
> Chetan Hosmani
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Transport Plugins Update

[Matthew Toseland]

On Wednesday 23 May 2012 18:00:40 Chetan Hosmani wrote:
> Hello everyone,
> 
> I have been a bit busy last week, and haven't committed much code.
> Here are the following refactor changes I have implemented and pushed
> to "refactor-1" branch-
> 
> 1. Added a separate list for transport managers. So we basically have
> a list which will contain a manager for every mode. Presently it has
> two - opennet and darknet.
> 
> 2. NodeCrypto functions in the following way-
> a. Transport managers are created in the node irrespective of whether
> opennet or darknet is running.
> b. NodeCrypto on creation for every mode accesses its respective
> transport manager to get a list of transports.
> c. It runs the method handleNewTransport to initialise a PacketMangler
> and handle each transport plugin.
> d. If the list of transports is empty, then it will function using the
> inherent UDPSocketHandler transport and run normally.
> d. When a plugin is loaded (on registering with TransportManager), the
> manager checks if the corresponding mode (opennet/darknet) exists and
> notifies the NodeCrypto by calling the handleNewTransport method.
> 
> 3. UDPSocketHandler now extends PacketTransportPlugin, and I have made
> changes so that it looks like a plugin. I have built it and checked.
> It runs fine.
> It also registers in the transport manager.
> 
> 4. Presently working on replacing the Session keys in the PeerNode
> object. There are three - current, previous and unverified. I am not
> yet well acquainted how these work.
> But the idea is to have a separate connection object PeerConnection that -
> a. Has a unique PeerNode
> b. Has a transport associated
> c. Has the corresponding Peer (detected Peer) object associated
> (different transports are on different ports, and we can keep it open
> to use different addresses itself)

This should be fairly similar to the current code. There are some complexities, 
e.g. : is not necessarily valid 
externally; this is why we include both that and the address/port that our 
peers tell us is our address/port number.

> d. A list of session keys. It need not be three. The code can become
> more generic.
> 
> So PeerNode has a list of PeerConnection objects, for every active
> transport. The PeerNode will decide the transport to use using these
> objects.

The rest looks good.
> 
> 
> The official coding period has started. So after a few more additions
> I will merge them to "Transports" branch and begin working on a new
> branch "PacketTransports".
> Also awaiting some code review, after nextgens becomes free.
> 
> For the coming week-
> 
> 1. Work and finish handleNewTransport
> 2. Finish the PeerConnection object
> 3. List the changes needed for multiple transport support in PeerNode
> (implementing PeerConnection list)
> 4. Figure out PeerNode code to use different transports
> 
> Later on I will mainly work on NewPacketFormat which needs to be
> changed so that they are more generic for Packet Transports. Hope to
> have toad's and zidel's help then.
> 
> ArneBab - Flog is coming too. Sorry :)
> 
> Regards,
> Chetan Hosmani


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins Update (GSoC)

[Chetan Hosmani]

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.
>
> 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?

Re: [freenet-dev] Transport Plugins Update (GSoC)

[Chetan Hosmani]

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.
>
> 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?
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins Update (GSoC)

[Steve Dougherty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJP1sasAAoJECLJP19KqmFuJ5IQAIpi/rM4hEUBXiHCv+u3RS9b
ktiEHhaL0+omcqyOASMxCDbQRuB0ngAa/bDghlL01U7cR1dTPOdkdoQ+/P//jvv2
P4jggu3llvnMhhU597X127PrZXM07A06oLvKO9DVumtpAprCuFVj77I1oLDabD7r
0u0pmMNuOoQ1PbVvv3KvbyIBQMVc63rkwGLwr0nE0tbwQ8+69iN5cvr/XN3x5zy8
OpsjF4t8fD/H6QfN6LeLWQ/xNvc6ObVuMHpc+h5DD+i26zUjWZbRk0nqMpgX/uC0
vAT4g2T8BS42S4TIuxa34M0FMIRyYYVaW5q63aqPDSx3ExL8JOvYXyen9wG7G4Qc
VEZS8eLK+KnedTOeeJ5JAWyL9M0oi6fez9XMr/gTtQ0lbZo7On6N1uCR/niyZT9h
42UCWgRgS9q3j1lsHCkfa/o/MHWqMLwsHIlMUwEr9FjHWu4COaQwNiGmPWkOacDi
bJRUU5ljpj2Q3VlglVrw38tezAPlcHfBaJJH148OHzLWU9T1WXmsQrhke6L08xDH
98JFMf3XzGGwcDBf5Sg0AhEn5KZALAyV51CXKLVKN0CWIo2R5hN8VQgAkL8RNLue
8C+YY+dtPqxfc1KcQ++5lwiPIxupyMd9xuA6b6W0Q40QNwCf63BW8ajbMnsErFuU
QbiWCECT5R90YYWXOlcE
=cBEf
-END PGP SIGNATURE-

[freenet-dev] Transport Plugins Update (GSoC)

[Chetan Hosmani]

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
packet transports. Ideally it would be great to finish it by midterm,
toad and nextgens suggest otherwise. Also after the transports start
running there would be several other issues that would need to be
worked upon.

Next 4-5 weeks (till the Midterm evaluations)-
1. Complete the above tasks, and complete handshake for different transports.
2. Work on refactoring and separating NewPacketFormat into two parts-
a) A common object for streams and packets to handle messages in
flight - PeerMessageTracker
b) An object for the packet creation, encryption, queueing, etc.
3. Begin implementing/running new transports (at the beginning I would
simply run the different instances of UDP plugin)
4. Finish basic UDP plugin - code mostly copied from UDPSocketHandler
5. Write a PoC steno plugin.

I am also in parallel implementing as much as possible of stream transport API.

Hope to get my code reviewed and commented soon. My flog updates are
ready too, but I haven't been able to run freenet, due to connectivity
issues. (Hope that will be resolved in a couple of days)

Thank you,
Chetan

Re: [freenet-dev] Transport Plugins Update (GSoC)

[Steve Dougherty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJP1sasAAoJECLJP19KqmFuJ5IQAIpi/rM4hEUBXiHCv+u3RS9b
ktiEHhaL0+omcqyOASMxCDbQRuB0ngAa/bDghlL01U7cR1dTPOdkdoQ+/P//jvv2
P4jggu3llvnMhhU597X127PrZXM07A06oLvKO9DVumtpAprCuFVj77I1oLDabD7r
0u0pmMNuOoQ1PbVvv3KvbyIBQMVc63rkwGLwr0nE0tbwQ8+69iN5cvr/XN3x5zy8
OpsjF4t8fD/H6QfN6LeLWQ/xNvc6ObVuMHpc+h5DD+i26zUjWZbRk0nqMpgX/uC0
vAT4g2T8BS42S4TIuxa34M0FMIRyYYVaW5q63aqPDSx3ExL8JOvYXyen9wG7G4Qc
VEZS8eLK+KnedTOeeJ5JAWyL9M0oi6fez9XMr/gTtQ0lbZo7On6N1uCR/niyZT9h
42UCWgRgS9q3j1lsHCkfa/o/MHWqMLwsHIlMUwEr9FjHWu4COaQwNiGmPWkOacDi
bJRUU5ljpj2Q3VlglVrw38tezAPlcHfBaJJH148OHzLWU9T1WXmsQrhke6L08xDH
98JFMf3XzGGwcDBf5Sg0AhEn5KZALAyV51CXKLVKN0CWIo2R5hN8VQgAkL8RNLue
8C+YY+dtPqxfc1KcQ++5lwiPIxupyMd9xuA6b6W0Q40QNwCf63BW8ajbMnsErFuU
QbiWCECT5R90YYWXOlcE
=cBEf
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins Update (GSoC)

[Chetan Hosmani]

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
packet transports. Ideally it would be great to finish it by midterm,
toad and nextgens suggest otherwise. Also after the transports start
running there would be several other issues that would need to be
worked upon.

Next 4-5 weeks (till the Midterm evaluations)-
1. Complete the above tasks, and complete handshake for different transports.
2. Work on refactoring and separating NewPacketFormat into two parts-
a) A common object for streams and packets to handle messages in
flight - PeerMessageTracker
b) An object for the packet creation, encryption, queueing, etc.
3. Begin implementing/running new transports (at the beginning I would
simply run the different instances of UDP plugin)
4. Finish basic UDP plugin - code mostly copied from UDPSocketHandler
5. Write a PoC steno plugin.

I am also in parallel implementing as much as possible of stream transport API.

Hope to get my code reviewed and commented soon. My flog updates are
ready too, but I haven't been able to run freenet, due to connectivity
issues. (Hope that will be resolved in a couple of days)

Thank you,
Chetan
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins Update

[Arne Babenhauserheide]

Hi Chetan,

Your changes sound good!

At Wed, 23 May 2012 22:30:40 +0530,
> The official coding period has started. So after a few more additions
> I will merge them to "Transports" branch and begin working on a new
> branch "PacketTransports".
> Also awaiting some code review, after nextgens becomes free.
> 
> For the coming week-
> 
> 1. Work and finish handleNewTransport
> 2. Finish the PeerConnection object
> 3. List the changes needed for multiple transport support in PeerNode
> (implementing PeerConnection list)
> 4. Figure out PeerNode code to use different transports
> 
> Later on I will mainly work on NewPacketFormat which needs to be
> changed so that they are more generic for Packet Transports. Hope to
> have toad's and zidel's help then.

Thanks for the overview!

> ArneBab - Flog is coming too. Sorry :)

:)

No worries. I?ll be glad to see it become more active, but I?ll be
mostly disconnected for the next 10 days anyway (we moved and don?t
yet have internet in the new home).

Best wishes,
Arne

Re: [freenet-dev] Transport Plugins Update

[Arne Babenhauserheide]

Hi Chetan,

Your changes sound good!

At Wed, 23 May 2012 22:30:40 +0530,
> The official coding period has started. So after a few more additions
> I will merge them to "Transports" branch and begin working on a new
> branch "PacketTransports".
> Also awaiting some code review, after nextgens becomes free.
> 
> For the coming week-
> 
> 1. Work and finish handleNewTransport
> 2. Finish the PeerConnection object
> 3. List the changes needed for multiple transport support in PeerNode
> (implementing PeerConnection list)
> 4. Figure out PeerNode code to use different transports
> 
> Later on I will mainly work on NewPacketFormat which needs to be
> changed so that they are more generic for Packet Transports. Hope to
> have toad's and zidel's help then.

Thanks for the overview!

> ArneBab - Flog is coming too. Sorry :)

:)

No worries. I’ll be glad to see it become more active, but I’ll be
mostly disconnected for the next 10 days anyway (we moved and don’t
yet have internet in the new home).

Best wishes,
Arne

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins Update

[Chetan Hosmani]

Hello everyone,

I have been a bit busy last week, and haven't committed much code.
Here are the following refactor changes I have implemented and pushed
to "refactor-1" branch-

1. Added a separate list for transport managers. So we basically have
a list which will contain a manager for every mode. Presently it has
two - opennet and darknet.

2. NodeCrypto functions in the following way-
a. Transport managers are created in the node irrespective of whether
opennet or darknet is running.
b. NodeCrypto on creation for every mode accesses its respective
transport manager to get a list of transports.
c. It runs the method handleNewTransport to initialise a PacketMangler
and handle each transport plugin.
d. If the list of transports is empty, then it will function using the
inherent UDPSocketHandler transport and run normally.
d. When a plugin is loaded (on registering with TransportManager), the
manager checks if the corresponding mode (opennet/darknet) exists and
notifies the NodeCrypto by calling the handleNewTransport method.

3. UDPSocketHandler now extends PacketTransportPlugin, and I have made
changes so that it looks like a plugin. I have built it and checked.
It runs fine.
It also registers in the transport manager.

4. Presently working on replacing the Session keys in the PeerNode
object. There are three - current, previous and unverified. I am not
yet well acquainted how these work.
But the idea is to have a separate connection object PeerConnection that -
a. Has a unique PeerNode
b. Has a transport associated
c. Has the corresponding Peer (detected Peer) object associated
(different transports are on different ports, and we can keep it open
to use different addresses itself)
d. A list of session keys. It need not be three. The code can become
more generic.

So PeerNode has a list of PeerConnection objects, for every active
transport. The PeerNode will decide the transport to use using these
objects.


The official coding period has started. So after a few more additions
I will merge them to "Transports" branch and begin working on a new
branch "PacketTransports".
Also awaiting some code review, after nextgens becomes free.

For the coming week-

1. Work and finish handleNewTransport
2. Finish the PeerConnection object
3. List the changes needed for multiple transport support in PeerNode
(implementing PeerConnection list)
4. Figure out PeerNode code to use different transports

Later on I will mainly work on NewPacketFormat which needs to be
changed so that they are more generic for Packet Transports. Hope to
have toad's and zidel's help then.

ArneBab - Flog is coming too. Sorry :)

Regards,
Chetan Hosmani

[freenet-dev] Transport Plugins Update

[Chetan Hosmani]

Hello everyone,

I have been a bit busy last week, and haven't committed much code.
Here are the following refactor changes I have implemented and pushed
to "refactor-1" branch-

1. Added a separate list for transport managers. So we basically have
a list which will contain a manager for every mode. Presently it has
two - opennet and darknet.

2. NodeCrypto functions in the following way-
a. Transport managers are created in the node irrespective of whether
opennet or darknet is running.
b. NodeCrypto on creation for every mode accesses its respective
transport manager to get a list of transports.
c. It runs the method handleNewTransport to initialise a PacketMangler
and handle each transport plugin.
d. If the list of transports is empty, then it will function using the
inherent UDPSocketHandler transport and run normally.
d. When a plugin is loaded (on registering with TransportManager), the
manager checks if the corresponding mode (opennet/darknet) exists and
notifies the NodeCrypto by calling the handleNewTransport method.

3. UDPSocketHandler now extends PacketTransportPlugin, and I have made
changes so that it looks like a plugin. I have built it and checked.
It runs fine.
It also registers in the transport manager.

4. Presently working on replacing the Session keys in the PeerNode
object. There are three - current, previous and unverified. I am not
yet well acquainted how these work.
But the idea is to have a separate connection object PeerConnection that -
a. Has a unique PeerNode
b. Has a transport associated
c. Has the corresponding Peer (detected Peer) object associated
(different transports are on different ports, and we can keep it open
to use different addresses itself)
d. A list of session keys. It need not be three. The code can become
more generic.

So PeerNode has a list of PeerConnection objects, for every active
transport. The PeerNode will decide the transport to use using these
objects.


The official coding period has started. So after a few more additions
I will merge them to "Transports" branch and begin working on a new
branch "PacketTransports".
Also awaiting some code review, after nextgens becomes free.

For the coming week-

1. Work and finish handleNewTransport
2. Finish the PeerConnection object
3. List the changes needed for multiple transport support in PeerNode
(implementing PeerConnection list)
4. Figure out PeerNode code to use different transports

Later on I will mainly work on NewPacketFormat which needs to be
changed so that they are more generic for Packet Transports. Hope to
have toad's and zidel's help then.

ArneBab - Flog is coming too. Sorry :)

Regards,
Chetan Hosmani
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins (Update)

[Marco Schulze]

Yes. Thank you.

On 15-05-2012 12:42, Chetan Hosmani wrote:
> On Tue, May 15, 2012 at 8:39 PM, Marco Schulze
>   wrote:
>> What about changes to the FNP when stream transports are used? How much
>> power will transport plugins have on the actual bytes being sent? For
>> example, it might be advantageous for the TCP plugin to use some kind of
>> PAUSE-MESSAGE marker to allow messages with higher priority to be sent as
>> soon as they are queued, instead of buffering/fragmenting/packing messages
>> for pack transports.
> Well I am not the best person to answer all of those questions.
> If you check my previous two posts on devl, it explains how streams
> will be supported, and what power the transport will have.
>
> But to summarize-
> 1. Simply put the plugin will not deal with any of this, or at least
> the plugin developer will not have to worry about messages.
> 2. The plugin will deal mainly with setting up the low level
> sockets/streams, and returning them to fred
> 3. Plugin will deal with parsing the data to be sent, adding headers,
> etc. This is to allow stenography.
> This the plugin will implement by copying pipestreams from fred,
> encoding appropriately, and sending it on its own streams.
>
> Plugin will not perform any cryptography or tracking
> messages-in-flight as such. toad's idea is to make it as simple as
> possible. I will implement a TCP plugin only to demonstrate it.
>
> I have two parts here - stream support and extending packet support
>
> Now my job (stream based architecture will mostly be the later phases
> of my project) for stream architecture-
> 1. Have separate implementations of StreamMangler (to setup the peer
> i.e. do handshake, save keys etc.)
> 2. Have a separate thread StreamConnectionHandler that will fetch
> messages, track them, etc. You can call it analogous to
> NewPacketFormat. They run their own loop and communicate with stream
> based transports like TCP.
>
> I think here is where your suggestion applies. Although I am not sure
> I am the right person to comment on it. But I think it can be
> implemented.
>
> Also extending packet support would involve multiple NewPacketFormat
> objects running in parallel. The peernode would choose a transport
> based on availability.
>
> Another point is that each transport will use a single common message
> queue, but they track them independently.
> The objective is for multiple transports to setup and do handshakes,
> run and send messages simultaneously.
>
> A lot of work after that would involve choosing the right transport,
> latency issues and so on. I hope to get the basic running architecture
> ready first.
>
> I hope I have answered your question :)
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Transport Plugins (Update)

[Marco Schulze]

Yes. Thank you.

On 15-05-2012 12:42, Chetan Hosmani wrote:

On Tue, May 15, 2012 at 8:39 PM, Marco Schulze
  wrote:

What about changes to the FNP when stream transports are used? How much
power will transport plugins have on the actual bytes being sent? For
example, it might be advantageous for the TCP plugin to use some kind of
PAUSE-MESSAGE marker to allow messages with higher priority to be sent as
soon as they are queued, instead of buffering/fragmenting/packing messages
for pack transports.

Well I am not the best person to answer all of those questions.
If you check my previous two posts on devl, it explains how streams
will be supported, and what power the transport will have.

But to summarize-
1. Simply put the plugin will not deal with any of this, or at least
the plugin developer will not have to worry about messages.
2. The plugin will deal mainly with setting up the low level
sockets/streams, and returning them to fred
3. Plugin will deal with parsing the data to be sent, adding headers,
etc. This is to allow stenography.
This the plugin will implement by copying pipestreams from fred,
encoding appropriately, and sending it on its own streams.

Plugin will not perform any cryptography or tracking
messages-in-flight as such. toad's idea is to make it as simple as
possible. I will implement a TCP plugin only to demonstrate it.

I have two parts here - stream support and extending packet support

Now my job (stream based architecture will mostly be the later phases
of my project) for stream architecture-
1. Have separate implementations of StreamMangler (to setup the peer
i.e. do handshake, save keys etc.)
2. Have a separate thread StreamConnectionHandler that will fetch
messages, track them, etc. You can call it analogous to
NewPacketFormat. They run their own loop and communicate with stream
based transports like TCP.

I think here is where your suggestion applies. Although I am not sure
I am the right person to comment on it. But I think it can be
implemented.

Also extending packet support would involve multiple NewPacketFormat
objects running in parallel. The peernode would choose a transport
based on availability.

Another point is that each transport will use a single common message
queue, but they track them independently.
The objective is for multiple transports to setup and do handshakes,
run and send messages simultaneously.

A lot of work after that would involve choosing the right transport,
latency issues and so on. I hope to get the basic running architecture
ready first.

I hope I have answered your question :)
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins (Update)

[Chetan Hosmani]

On Tue, May 15, 2012 at 8:39 PM, Marco Schulze
 wrote:
> What about changes to the FNP when stream transports are used? How much
> power will transport plugins have on the actual bytes being sent? For
> example, it might be advantageous for the TCP plugin to use some kind of
> PAUSE-MESSAGE marker to allow messages with higher priority to be sent as
> soon as they are queued, instead of buffering/fragmenting/packing messages
> for pack transports.

Well I am not the best person to answer all of those questions.
If you check my previous two posts on devl, it explains how streams
will be supported, and what power the transport will have.

But to summarize-
1. Simply put the plugin will not deal with any of this, or at least
the plugin developer will not have to worry about messages.
2. The plugin will deal mainly with setting up the low level
sockets/streams, and returning them to fred
3. Plugin will deal with parsing the data to be sent, adding headers,
etc. This is to allow stenography.
This the plugin will implement by copying pipestreams from fred,
encoding appropriately, and sending it on its own streams.

Plugin will not perform any cryptography or tracking
messages-in-flight as such. toad's idea is to make it as simple as
possible. I will implement a TCP plugin only to demonstrate it.

I have two parts here - stream support and extending packet support

Now my job (stream based architecture will mostly be the later phases
of my project) for stream architecture-
1. Have separate implementations of StreamMangler (to setup the peer
i.e. do handshake, save keys etc.)
2. Have a separate thread StreamConnectionHandler that will fetch
messages, track them, etc. You can call it analogous to
NewPacketFormat. They run their own loop and communicate with stream
based transports like TCP.

I think here is where your suggestion applies. Although I am not sure
I am the right person to comment on it. But I think it can be
implemented.

Also extending packet support would involve multiple NewPacketFormat
objects running in parallel. The peernode would choose a transport
based on availability.

Another point is that each transport will use a single common message
queue, but they track them independently.
The objective is for multiple transports to setup and do handshakes,
run and send messages simultaneously.

A lot of work after that would involve choosing the right transport,
latency issues and so on. I hope to get the basic running architecture
ready first.

I hope I have answered your question :)

[freenet-dev] Transport Plugins (Update)

[Chetan Hosmani]

On Tue, May 15, 2012 at 1:44 PM, Marco Schulze
 wrote:
> Nice! Which transport plugins you are planning to implement?
>

Thank you!
Actually as proof of concept I ll implement a simple TCP plugin. Also
as a long term goal I'll make existing UDP as a plugin.

[freenet-dev] Transport Plugins (Update)

[Chetan Hosmani]

Hello,

Sorry for the previous very lengthy update. I'll keep this one short.

After several discussions the basic idea of how I'll implement
transports is now clear.
I have begun writing some basic plugin architecture. The same has been
committed to the branch "refactor-1". I intend to finish, by the end
of this week, refactoring portions of code from NodeCrypto. The main
objective is to remove the "dependence on a single socket object"

Currently I have submitted code on the following new classes-

https://github.com/chetanhosmani/fred-staging/tree/refactor-1

1. TransportManager - This will now contain a list of available
transports (packet transports and stream transports). Transports
register here to let the node know of its availability.
2. TransportPlugin - A base class for the transports
3. StreamTransportPlugin - Base class for stream based transports. It
mainly supports a "connect" method and a "listen" method.
4. PacketTransportPlugin - This is based on PacketSocketHandler itself.

One issue I had was regarding opennet and darknet modes. So I have
extended the plugins so that these methods know the mode of operation
through a boolean. I am not sure if this is okay, though it is a bit
crude. The plugin will provide separate sockets for opennet and
darknet modes. The node side classes only need to mention this through
the "isOpennet" variable.

For the coming week the objective is to remove any "dependence on a
single socket object". So I am working on it in the following way-

Create TransportManager class for a node. Will list all transports
irrespective of darknet and opennet mode. So this means there will be
no issue when opennet is enabled later on.
This will be followed by changing-
NodeCrypto to handle new transports
PeerNode to use new transports

I am sorry I have not been able to update the flog. I will do some
short updates there too.

Regards,
Chetan





toad - Need specific advice on this part.
Scenario 1 - transport plugin added after initialization of nodecrypto
(say darknet).
Scenario 2 - Opennet enabled after transport plugin is loaded.

So transportmanager can be the class in between.

1. To handle new transports plugins coming in-
Transport registers, TransportManager calls on NodeCrypto (maybe
handleNewTransport(...) ) to handle the new transport for opennet and
darknet modes

2. To handle new mode (opennet) after transport plugins are loaded
The new nodecrypto checks for available transports and uses them at
initialization.

So I suppose it is okay to retain UDPSocketHandler as a default when
transports are not yet loaded? I hope this is okay with you?

Also as I mentioned here and on IRC, about using a boolean to
distinguish between opennet and darknet, which the plugin takes care
of. Is that also fine with you?
Do let me know :)

[freenet-dev] Transport Plugins (Update)

[Marco Schulze]

What about changes to the FNP when stream transports are used? How much 
power will transport plugins have on the actual bytes being sent? For 
example, it might be advantageous for the TCP plugin to use some kind of 
PAUSE-MESSAGE marker to allow messages with higher priority to be sent 
as soon as they are queued, instead of buffering/fragmenting/packing 
messages for pack transports.

On 15-05-2012 06:20, Chetan Hosmani wrote:
> On Tue, May 15, 2012 at 1:44 PM, Marco Schulze
>   wrote:
>> Nice! Which transport plugins you are planning to implement?
>>
> Thank you!
> Actually as proof of concept I ll implement a simple TCP plugin. Also
> as a long term goal I'll make existing UDP as a plugin.
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Transport Plugins (Update)

[Chetan Hosmani]

On Tue, May 15, 2012 at 8:39 PM, Marco Schulze
 wrote:
> What about changes to the FNP when stream transports are used? How much
> power will transport plugins have on the actual bytes being sent? For
> example, it might be advantageous for the TCP plugin to use some kind of
> PAUSE-MESSAGE marker to allow messages with higher priority to be sent as
> soon as they are queued, instead of buffering/fragmenting/packing messages
> for pack transports.

Well I am not the best person to answer all of those questions.
If you check my previous two posts on devl, it explains how streams
will be supported, and what power the transport will have.

But to summarize-
1. Simply put the plugin will not deal with any of this, or at least
the plugin developer will not have to worry about messages.
2. The plugin will deal mainly with setting up the low level
sockets/streams, and returning them to fred
3. Plugin will deal with parsing the data to be sent, adding headers,
etc. This is to allow stenography.
This the plugin will implement by copying pipestreams from fred,
encoding appropriately, and sending it on its own streams.

Plugin will not perform any cryptography or tracking
messages-in-flight as such. toad's idea is to make it as simple as
possible. I will implement a TCP plugin only to demonstrate it.

I have two parts here - stream support and extending packet support

Now my job (stream based architecture will mostly be the later phases
of my project) for stream architecture-
1. Have separate implementations of StreamMangler (to setup the peer
i.e. do handshake, save keys etc.)
2. Have a separate thread StreamConnectionHandler that will fetch
messages, track them, etc. You can call it analogous to
NewPacketFormat. They run their own loop and communicate with stream
based transports like TCP.

I think here is where your suggestion applies. Although I am not sure
I am the right person to comment on it. But I think it can be
implemented.

Also extending packet support would involve multiple NewPacketFormat
objects running in parallel. The peernode would choose a transport
based on availability.

Another point is that each transport will use a single common message
queue, but they track them independently.
The objective is for multiple transports to setup and do handshakes,
run and send messages simultaneously.

A lot of work after that would involve choosing the right transport,
latency issues and so on. I hope to get the basic running architecture
ready first.

I hope I have answered your question :)
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Transport Plugins (Update)

[Marco Schulze]

What about changes to the FNP when stream transports are used? How much 
power will transport plugins have on the actual bytes being sent? For 
example, it might be advantageous for the TCP plugin to use some kind of 
PAUSE-MESSAGE marker to allow messages with higher priority to be sent 
as soon as they are queued, instead of buffering/fragmenting/packing 
messages for pack transports.


On 15-05-2012 06:20, Chetan Hosmani wrote:

On Tue, May 15, 2012 at 1:44 PM, Marco Schulze
  wrote:

Nice! Which transport plugins you are planning to implement?


Thank you!
Actually as proof of concept I ll implement a simple TCP plugin. Also
as a long term goal I'll make existing UDP as a plugin.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins (Update)

[Marco Schulze]

Nice! Which transport plugins you are planning to implement?

On 15-05-2012 04:13, Chetan Hosmani wrote:
> Hello,
>
> Sorry for the previous very lengthy update. I'll keep this one short.
>
> After several discussions the basic idea of how I'll implement
> transports is now clear.
> I have begun writing some basic plugin architecture. The same has been
> committed to the branch "refactor-1". I intend to finish, by the end
> of this week, refactoring portions of code from NodeCrypto. The main
> objective is to remove the "dependence on a single socket object"
>
> Currently I have submitted code on the following new classes-
>
> https://github.com/chetanhosmani/fred-staging/tree/refactor-1
>
> 1. TransportManager - This will now contain a list of available
> transports (packet transports and stream transports). Transports
> register here to let the node know of its availability.
> 2. TransportPlugin - A base class for the transports
> 3. StreamTransportPlugin - Base class for stream based transports. It
> mainly supports a "connect" method and a "listen" method.
> 4. PacketTransportPlugin - This is based on PacketSocketHandler itself.
>
> One issue I had was regarding opennet and darknet modes. So I have
> extended the plugins so that these methods know the mode of operation
> through a boolean. I am not sure if this is okay, though it is a bit
> crude. The plugin will provide separate sockets for opennet and
> darknet modes. The node side classes only need to mention this through
> the "isOpennet" variable.
>
> For the coming week the objective is to remove any "dependence on a
> single socket object". So I am working on it in the following way-
>
> Create TransportManager class for a node. Will list all transports
> irrespective of darknet and opennet mode. So this means there will be
> no issue when opennet is enabled later on.
> This will be followed by changing-
> NodeCrypto to handle new transports
> PeerNode to use new transports
>
> I am sorry I have not been able to update the flog. I will do some
> short updates there too.
>
> Regards,
> Chetan
>
>
>
>
>
> toad - Need specific advice on this part.
> Scenario 1 - transport plugin added after initialization of nodecrypto
> (say darknet).
> Scenario 2 - Opennet enabled after transport plugin is loaded.
>
> So transportmanager can be the class in between.
>
> 1. To handle new transports plugins coming in-
> Transport registers, TransportManager calls on NodeCrypto (maybe
> handleNewTransport(...) ) to handle the new transport for opennet and
> darknet modes
>
> 2. To handle new mode (opennet) after transport plugins are loaded
> The new nodecrypto checks for available transports and uses them at
> initialization.
>
> So I suppose it is okay to retain UDPSocketHandler as a default when
> transports are not yet loaded? I hope this is okay with you?
>
> Also as I mentioned here and on IRC, about using a boolean to
> distinguish between opennet and darknet, which the plugin takes care
> of. Is that also fine with you?
> Do let me know :)
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Transport Plugins (Update)

[Chetan Hosmani]

On Tue, May 15, 2012 at 1:44 PM, Marco Schulze
 wrote:
> Nice! Which transport plugins you are planning to implement?
>

Thank you!
Actually as proof of concept I ll implement a simple TCP plugin. Also
as a long term goal I'll make existing UDP as a plugin.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Transport Plugins (Update)

[Marco Schulze]

Nice! Which transport plugins you are planning to implement?

On 15-05-2012 04:13, Chetan Hosmani wrote:

Hello,

Sorry for the previous very lengthy update. I'll keep this one short.

After several discussions the basic idea of how I'll implement
transports is now clear.
I have begun writing some basic plugin architecture. The same has been
committed to the branch "refactor-1". I intend to finish, by the end
of this week, refactoring portions of code from NodeCrypto. The main
objective is to remove the "dependence on a single socket object"

Currently I have submitted code on the following new classes-

https://github.com/chetanhosmani/fred-staging/tree/refactor-1

1. TransportManager - This will now contain a list of available
transports (packet transports and stream transports). Transports
register here to let the node know of its availability.
2. TransportPlugin - A base class for the transports
3. StreamTransportPlugin - Base class for stream based transports. It
mainly supports a "connect" method and a "listen" method.
4. PacketTransportPlugin - This is based on PacketSocketHandler itself.

One issue I had was regarding opennet and darknet modes. So I have
extended the plugins so that these methods know the mode of operation
through a boolean. I am not sure if this is okay, though it is a bit
crude. The plugin will provide separate sockets for opennet and
darknet modes. The node side classes only need to mention this through
the "isOpennet" variable.

For the coming week the objective is to remove any "dependence on a
single socket object". So I am working on it in the following way-

Create TransportManager class for a node. Will list all transports
irrespective of darknet and opennet mode. So this means there will be
no issue when opennet is enabled later on.
This will be followed by changing-
NodeCrypto to handle new transports
PeerNode to use new transports

I am sorry I have not been able to update the flog. I will do some
short updates there too.

Regards,
Chetan





toad - Need specific advice on this part.
Scenario 1 - transport plugin added after initialization of nodecrypto
(say darknet).
Scenario 2 - Opennet enabled after transport plugin is loaded.

So transportmanager can be the class in between.

1. To handle new transports plugins coming in-
Transport registers, TransportManager calls on NodeCrypto (maybe
handleNewTransport(...) ) to handle the new transport for opennet and
darknet modes

2. To handle new mode (opennet) after transport plugins are loaded
The new nodecrypto checks for available transports and uses them at
initialization.

So I suppose it is okay to retain UDPSocketHandler as a default when
transports are not yet loaded? I hope this is okay with you?

Also as I mentioned here and on IRC, about using a boolean to
distinguish between opennet and darknet, which the plugin takes care
of. Is that also fine with you?
Do let me know :)
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins (Update)

[Chetan Hosmani]

Hello,

Sorry for the previous very lengthy update. I'll keep this one short.

After several discussions the basic idea of how I'll implement
transports is now clear.
I have begun writing some basic plugin architecture. The same has been
committed to the branch "refactor-1". I intend to finish, by the end
of this week, refactoring portions of code from NodeCrypto. The main
objective is to remove the "dependence on a single socket object"

Currently I have submitted code on the following new classes-

https://github.com/chetanhosmani/fred-staging/tree/refactor-1

1. TransportManager - This will now contain a list of available
transports (packet transports and stream transports). Transports
register here to let the node know of its availability.
2. TransportPlugin - A base class for the transports
3. StreamTransportPlugin - Base class for stream based transports. It
mainly supports a "connect" method and a "listen" method.
4. PacketTransportPlugin - This is based on PacketSocketHandler itself.

One issue I had was regarding opennet and darknet modes. So I have
extended the plugins so that these methods know the mode of operation
through a boolean. I am not sure if this is okay, though it is a bit
crude. The plugin will provide separate sockets for opennet and
darknet modes. The node side classes only need to mention this through
the "isOpennet" variable.

For the coming week the objective is to remove any "dependence on a
single socket object". So I am working on it in the following way-

Create TransportManager class for a node. Will list all transports
irrespective of darknet and opennet mode. So this means there will be
no issue when opennet is enabled later on.
This will be followed by changing-
NodeCrypto to handle new transports
PeerNode to use new transports

I am sorry I have not been able to update the flog. I will do some
short updates there too.

Regards,
Chetan





toad - Need specific advice on this part.
Scenario 1 - transport plugin added after initialization of nodecrypto
(say darknet).
Scenario 2 - Opennet enabled after transport plugin is loaded.

So transportmanager can be the class in between.

1. To handle new transports plugins coming in-
Transport registers, TransportManager calls on NodeCrypto (maybe
handleNewTransport(...) ) to handle the new transport for opennet and
darknet modes

2. To handle new mode (opennet) after transport plugins are loaded
The new nodecrypto checks for available transports and uses them at
initialization.

So I suppose it is okay to retain UDPSocketHandler as a default when
transports are not yet loaded? I hope this is okay with you?

Also as I mentioned here and on IRC, about using a boolean to
distinguish between opennet and darknet, which the plugin takes care
of. Is that also fine with you?
Do let me know :)
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins: Update (GSoC 2012)

[Chetan Hosmani]

Oh crap, that is very long. Nevermind. If any part is relevant do comment!

[freenet-dev] Transport Plugins: Update (GSoC 2012)

[Chetan Hosmani]

Hello,

This is an update on the first stage of my project. I have been
working out the details regarding modifications in the core to
simplify the implementation of the transport plugins. This refactoring
stage will involve some minor modifications and some major ones. These
are based on the discussions on #freenet and #freenet-chat. However I
would like to avoid doing changes that would bring about major
differences in the way things function at present.

I have planned to finish refactoring by May 21 (official coding begins
for GSoC). I intend to do that in 3 stages. I have also simultaneously
discussed the entire implementation of transport plugins here. I will
review the feedback and this report, to evaluate what constitutes the
refactoring. After those changes are made I can work on implementing
the needed core level changes, which mostly involve design for
streams.

1) Cryptography and Node

This will involve mainly the classes NodeCrypto and Node. I intend to
make NodeCrypto function purely for keys and not do any network
related task. Presently it also handles binding to the port, selection
of ports for Darknet mode and Opennet mode.
I am considering moving these portions to TransportManager and
PortManager classes.

TransportManager - A registry of registered transports with other
information. Initially I ll dump the refactor changes of UDP into it.
Later on, once UDP is ready as a plugin, along with TCP, it ll be a
generic class for any transport. There will be two objects of this -
one each for opennet and darknet modes.  NodeCrypto e.g. queries
TransportManager to find all the transports' addresses (as strings) to
put in the noderef.

Now UDPSocketHandler is equivalent to a UDP transport plugin, only
it's currently part of the core of freenet. So for the moment
TransportManager can communicate with UDPSocketHandler. That I believe
will be an intermediate step before actually converting
UDPSokcetHandler to a plugin.

PortManager - A registry of all active ports used by freenet - 1) List
of ports on fproxy page 2) List of ports for UPnP
Must contain - 1)Port number 2)Socket(TCP/UDP) 3)Forwarded
4)Description 5)Transport reference
However PortManager is second priority, and will not be addressed if
time does not permit.

Also a major refactoring change would be regarding the fact that
objects no longer take a socket or a port for granted. All queries
must go through the TransportManager. I would need help at certain
places to figure out how this can achieved. For e.g.
NodeCrypto/Node/some other classes assume that an unique darknet port
exists. toad suggested we use a debugging identifier here(some default
number, etc). That makes it simpler for me too.

2) Messages and Packets

These part have been discussed on #freenet(and #freenet-chat) and here
are some issues and conclusions-

a. The existing architecture supports only packet based transports.
The first step would be to draw a clear distinction between
packet-based(connectionless sockets) and stream-based(connection-based
sockets). Thus we will need separate classes for streams(with a base
class for streams and packets), that will handle Message-in-flight and
Packets-in-flight, tracking them, allowing for transports to be
switched midway. This will be handled differently in streams. For
Packets the existing classes can be used, however with modifications
to address the following.

b. For streams we need two features - To handle messages as a whole
entity, and acknowledge once an entire message has been received; and
To support partial messages, if for e.g. we have just switched from
UDP to TCP or we are sending a really large message on TCP.

c. NewPacketFormat currently 1) takes a byte[] from UdpSocketHandler
and decodes it 2) creates and sends a packet. Now the idea is to
create NewStreamFormat that handles streams, and also provide a pair
of streams StreamConnectionHandler for the plugin to write/read.
NewPacketFormat handles the list of message-in-flight. A new object
must be used for this purpose while NewPacketFormat performs lesser
tasks. Both NewPacketFormat and NewStreamFormat can communicate with
it.

Question: MessageWrapper tracks a message-in-flight. But is it really
necessary to create a base class for MessageWrapper and create
StreamMessageWrapper too. Or would it be simple to make necessary
modifications(if there are any) to MessageWrapper.
Please explain the purpose of doing so, as I have very little
understanding, as of now, of the object Message. Also how it will be
treated differently for streams against packets.

d. Another issue is regarding FNPPacketMangler. This is an important
aspect of freenet, as it deals with the handshake between two nodes,
and the exchange of cryptographic keys. So the issue being whether per
NodeCrypto we have an object or per transport we have an object, of
the FNPPacketMangler type. And assuming these are packet based
transports.

Question: How can the equivalent of FNPPacketMangler be create

Re: [freenet-dev] Transport Plugins: Update (GSoC 2012)

[Chetan Hosmani]

Oh crap, that is very long. Nevermind. If any part is relevant do comment!
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Transport Plugins: Update (GSoC 2012)

[Chetan Hosmani]

Hello,

This is an update on the first stage of my project. I have been
working out the details regarding modifications in the core to
simplify the implementation of the transport plugins. This refactoring
stage will involve some minor modifications and some major ones. These
are based on the discussions on #freenet and #freenet-chat. However I
would like to avoid doing changes that would bring about major
differences in the way things function at present.

I have planned to finish refactoring by May 21 (official coding begins
for GSoC). I intend to do that in 3 stages. I have also simultaneously
discussed the entire implementation of transport plugins here. I will
review the feedback and this report, to evaluate what constitutes the
refactoring. After those changes are made I can work on implementing
the needed core level changes, which mostly involve design for
streams.

1) Cryptography and Node

This will involve mainly the classes NodeCrypto and Node. I intend to
make NodeCrypto function purely for keys and not do any network
related task. Presently it also handles binding to the port, selection
of ports for Darknet mode and Opennet mode.
I am considering moving these portions to TransportManager and
PortManager classes.

TransportManager - A registry of registered transports with other
information. Initially I ll dump the refactor changes of UDP into it.
Later on, once UDP is ready as a plugin, along with TCP, it ll be a
generic class for any transport. There will be two objects of this -
one each for opennet and darknet modes.  NodeCrypto e.g. queries
TransportManager to find all the transports' addresses (as strings) to
put in the noderef.

Now UDPSocketHandler is equivalent to a UDP transport plugin, only
it's currently part of the core of freenet. So for the moment
TransportManager can communicate with UDPSocketHandler. That I believe
will be an intermediate step before actually converting
UDPSokcetHandler to a plugin.

PortManager - A registry of all active ports used by freenet - 1) List
of ports on fproxy page 2) List of ports for UPnP
Must contain - 1)Port number 2)Socket(TCP/UDP) 3)Forwarded
4)Description 5)Transport reference
However PortManager is second priority, and will not be addressed if
time does not permit.

Also a major refactoring change would be regarding the fact that
objects no longer take a socket or a port for granted. All queries
must go through the TransportManager. I would need help at certain
places to figure out how this can achieved. For e.g.
NodeCrypto/Node/some other classes assume that an unique darknet port
exists. toad suggested we use a debugging identifier here(some default
number, etc). That makes it simpler for me too.

2) Messages and Packets

These part have been discussed on #freenet(and #freenet-chat) and here
are some issues and conclusions-

a. The existing architecture supports only packet based transports.
The first step would be to draw a clear distinction between
packet-based(connectionless sockets) and stream-based(connection-based
sockets). Thus we will need separate classes for streams(with a base
class for streams and packets), that will handle Message-in-flight and
Packets-in-flight, tracking them, allowing for transports to be
switched midway. This will be handled differently in streams. For
Packets the existing classes can be used, however with modifications
to address the following.

b. For streams we need two features - To handle messages as a whole
entity, and acknowledge once an entire message has been received; and
To support partial messages, if for e.g. we have just switched from
UDP to TCP or we are sending a really large message on TCP.

c. NewPacketFormat currently 1) takes a byte[] from UdpSocketHandler
and decodes it 2) creates and sends a packet. Now the idea is to
create NewStreamFormat that handles streams, and also provide a pair
of streams StreamConnectionHandler for the plugin to write/read.
NewPacketFormat handles the list of message-in-flight. A new object
must be used for this purpose while NewPacketFormat performs lesser
tasks. Both NewPacketFormat and NewStreamFormat can communicate with
it.

Question: MessageWrapper tracks a message-in-flight. But is it really
necessary to create a base class for MessageWrapper and create
StreamMessageWrapper too. Or would it be simple to make necessary
modifications(if there are any) to MessageWrapper.
Please explain the purpose of doing so, as I have very little
understanding, as of now, of the object Message. Also how it will be
treated differently for streams against packets.

d. Another issue is regarding FNPPacketMangler. This is an important
aspect of freenet, as it deals with the handshake between two nodes,
and the exchange of cryptographic keys. So the issue being whether per
NodeCrypto we have an object or per transport we have an object, of
the FNPPacketMangler type. And assuming these are packet based
transports.

Question: How can the equivalent of FNPPacketMangler be create