gmane.network.freenet.devel

Re: Statistics Project Update #4

Steve Dougherty — 2012-05-24T17:04:13

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2012 12:48 PM, Zlatin Balevsky wrote:

Currently at each hop the HTL is capped to the maximum HTL. Is this
what you mean? I can see why you'd want to cap to something smaller then.


That's somewhat of an issue: I don't think these number-of-appearance
CDFs are a good way to show effectiveness, but I don't know how else
to visualize it.


By all means! We're planning to have another review session in
#freenet either Friday May 25th shortly after 3:15 BST or sometime
Saturday, depending on when toad_ has time. You and any others are
very welcome to join the discussion!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPvmoNAAoJECLJP19KqmFu3i8QAI9zCbqpUZGZ+UzBDqYAMQya
PSdB/WOWIiuare1FfC8X/IPLC2NzPwZJNLguZJXiaRphJwDWUrKfdlcaav/F1t8U
kIQNGcdvNf1SAPpRm/dyo1U6N60bj7J3cMVN2NXWVJdi/qHZmpHj++2Nm0QrEo1g
yUmL09v+eZqCjBfDt+S/+wRuppn6zbuUgcLrTtPnlfvj3/3FKjFaJyti4f7LuN97
BzXYfydw6iQmwP6aMIPZ+f/aT7W6T7PXUclnSdQckJi5wl4eoZJ/C2g6AX4CK6Rv
RY2zG1wBpXZdoWIoG6jkHU9YrdYHi+kYsBtpQe2qNxznNEOVXlzjpRH69I2Ld831
gEifMIbVAJlEyH1dtDSTrZwjZJCpfl/C+0agCyXTlpWGLoKkKk2od0MwECY4Hw12
egvqIlTuArMD27gohJxAIOiSsgX7Mux7J1GCXuv4R4voMidPuj1JwvVYzIlSHQsO
8pIwFXjGFQLeKtsNTH045vyUeQ0++Lrq1qBTpOZm7XtBfhpB+vzUqHL2IwOdxlGj
RiSDLHXpekrjqq+dJju6Iz2jNTJvDZfD/LkdM8lxE83vqinik5hk4DHzb9qR2JER
BlPjIxs3jVvVRIiACFy8CShBUuk0jsSYTEAEuyjErPfDPnj9REqg2fdW8Lqe0hiM
zcssQFCqgyCFY9HXq6QL
=YNFP
-----END PGP SIGNATURE-----

Re: Statistics Project Update #4

Zlatin Balevsky — 2012-05-24T16:48:33

The way we dealt with this problem in Gnutella was to cap the max htl at
each hop.  Even if an attacker sent a message with very high htl each node
on the path would reduce it to a small value before forwarding.  Not sure
if this will work with Freenet.


can you tell what is the absolutely lowest htl value that will give "good
enough" performance?


We should discuss this in more detail and have more people involved before
releasing these changes.  I can see evanbd's point but the side effects of
very high htl must be taken into account as well.
_______________________________________________
Devl mailing list
Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: Statistics Project Update #4

Steve Dougherty — 2012-05-24T14:21:15

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/23/2012 10:47 PM, Zlatin Balevsky wrote:

Good point. I'm not sure what to do to improve that behavior though. I
can add some rate limiting if that looks like it'll be necessary.


Indeed it is possible to simulate, and that was the subject of my
second update on this project. [1] My main findings are here, [2]
where one can see that it's true that an HTL of 5 or 10 or so could
provide pretty good distribution already.

evanbd, my mentor for this project, suggested the maximum HTL of 50.
Here's some of his reasoning from the #freenet logs:

2012-05-09:
"So it looks to me from the graphs like HTL 20 is plenty for the new
probes. Which I take to mean we should set the default HTL as at least
30, possibly 40. Because your nice simulated graphs don't have
problematic behaviors like clustering or partitioning or whatever :)
Basically, I think we should have a fairly high *maximum* HTL (at
least 50), and have the actual HTL be a user-specified parameter."

2012-05-19:
"And the plan is to send the requests at < max HTL, assuming that we
don't need the full 50. It looked from graphs like 20 was sufficient,
so I want to send at 30."

Thanks,
operhiem1

[1] https://emu.freenetproject.org/pipermail/devl/2012-May/036373.html
[2] http://imgur.com/a/Z8SBS#2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPvkPRAAoJECLJP19KqmFubrYQAIhYpXGr/vKjwjVGKHMdyKD4
O+ZQUlrabCBojO6aKAxFNMiTPNlnJTijcylzYcTvtTp/K3jx8IgAC/rIlNDUFBXJ
mmM/9DoIVHKdLAtG6MEqFnMZO7xU3UnCijL557gp3beMLNvvJ0akP75xXM6vDJhr
dFtxA7yysSgydFk4v+aUYm/JntpRuCEAKgR5XyKOo/KeiXIyv4L0zOhoTc5pbf+N
bTqfz2Udx1x/liPNcxaznNhB7oxcAwEZFcTacDc44AJ475T2ta4JUnRwoCbNM+Lb
VAXl8ArO1oBqrpy1+2GSivyz4pKNKvU7ItJR6/ok/TX3rePjUNkbYrx92NfidDZ5
vjkc8BR1C2NiGa5gC0PySK40tJYwNnOAnTSYusnSaEIIXE0YrDuM3WXJsyQE2i/v
+V88os8J8rIdygzQDsukjD7krCuR0WCJDDalF19NkI+fiCdMF15KbJlWaGYBwtl+
rBeWSdHd9QrtTyZR/721YWOWj9tMUirK0xXKFe1LZh+tIG61xkSBYXZlqbpvbnJv
A9UGcvPBIw3tFTel+VR0NsjVhmsbmdyZdxCI8je3lc6y0iDE1IsgvdTWxpK8Ix1R
jjIEUcGK+ft7zFKXZx6UGFfezLaDvjX7VrNbCMSReAbz0Go0IuVDv3vY17LTtR2k
4jcYo5sZxYWlDZYPX1Cx
=kWS1
-----END PGP SIGNATURE-----

Re: Transport Plugins Update

Arne Babenhauserheide — 2012-05-24T08:06:02

Hi Chetan,

Your changes sound good!

At Wed, 23 May 2012 22:30:40 +0530,

Thanks for the overview!


:)

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< at >freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: Statistics Project Update #4

Zlatin Balevsky — 2012-05-24T02:47:25


On a global scale, the if the rate of new probe requests is higher
than the rate at which existing ones expire the number of active
probes at any moment will not reach balance.   Higher HTL makes a ddos
against the probe mechanism easier; in this scenario the internal
limit of 5 simultaneous probes ends up assisting the attacker.

Would it be possible to simulate a single-digit HTL network?  My
intuition suggests the graph of effectiveness of probes vs. HTL has a
logarithmic shape.

Transport Plugins Update

Chetan Hosmani — 2012-05-23T17:00:40

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

Re: Statistics Project Update #4

Steve Dougherty — 2012-05-22T01:41:29

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2012 07:46 PM, Zlatin Balevsky wrote:

In what ways could I do effective rate-limiting? Would it work to keep
track of when the last request was received from each peer, and send a
rate limiting error when the last request was too recent and the last
rate error sent to that peer was long enough ago?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPuu7JAAoJECLJP19KqmFurfgP/1E4S/bdp9gVyUWmH02z6Ccu
BTtwoSzR9Iw2c3y1UrvLvQhinCrqmuxzG7dcidU3MmfvQvbGVOUFqZZguTGhoPcj
bjoJAZgYkwR/398c4ople2HKcyuAAbISg8HHlQ2Y+MV4XBVqaLSgncrLVbuS3Qg5
Fx+mQZ9L2OrPzTKbNvgdk+P1sc2BCo2sHp6s6gElyAuaPDsyClQKDn64qg4FfpxU
R9SweaN4H2qaGEhRjNBy4gm9tdX3Yv0Gvbkr66EkH0bbtcNHg92d6Hn3Xu/wn3Tg
gmF/p5XVLcUmgbGUkd0ziOArHGVWHBxybNB5tg3GtBC+EAA4FKgn4sP9j4rEbpKY
MQCFbbzpOQPL1uS7YGC1Ut19dfPp03GTQzAxqDrSJ0kPLjwSzHFzaPJSLEh0VJFT
ONfQxaLHgrdUyQo5RAekl6ra94TyWExTrRbMBQuvp5gTiSufvxpH3pdZRb3WJGw7
Ok+ZYlxm+K7muixOGBFCSOz1Zdx78xJ9aLqb+lZi2Bj+0WW0kRjvW9UYh4x6pg98
GMydDQosUYxHkBcctLgjVbjEF0cr3soEI1yTOmJ0KRYgn0h+Cip25rhgVzRPMYn0
qxUl4xvPkXhxKcbkRy8Pxc1JHUMyNh+IammM2l5CiZw0k6TFSDT43rMjEwBwsSnJ
t3UhSHnew4maBVlL9Bnv
=psgK
-----END PGP SIGNATURE-----

Re: Statistics Project Update #4

Steve Dougherty — 2012-05-22T00:17:25

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/21/2012 07:46 PM, Zlatin Balevsky wrote:

They're limited in that each node will only accept 5 simultaneous
probes. For these purposes, probes with equal randomly assigned (in
the current code; an adversary could do something different) UIDs are
considered to be the same probe.

I haven't added any rate limiting myself. If something at the
NodeDispatcher level or below has rate limiting for all messages which
pass through them then the probes would have it. In checking just now
I didn't notice any, but I don't know.


Perhaps I should add a metric like "probe requests accepted in the
past hour"? All that occurs to me is logging MHProbe at debug,
grepping the logs for "Accepting probe with uid ", counting the lines.


I don't follow. What do you mean? At each hop a probe either stays
locally (if a candidate is not accepted) or is routed to another
random node.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPutsVAAoJECLJP19KqmFuf9cQAKPlMhqZ6iYPBORXaYQEAKak
Dq8jM4IZVJTv6qpxwgGzEUre6j2SyHU8l6p0ga7EY/A5xLXT8mrc8ykuUWqUnb3d
l9ZYqBp++BADrvbL+ETIXXzbD9RjR4uM+HWdVliC8INGoPHUOjZgLuQm7TFMLVI1
Gu4FulIoc1f+9VE+Gai+y+LulrXwplnOSwL8RaKijFJfyDPGCqTNK6JjUV1G7zsw
OR7txfcoWv2S5qJkqCW2Kjgfnb9wfvOWZaLz++26OlxWdkQ24GxcBtpH3WEUM1WT
HyIwRwEuk/TRsEOkf794LTxpHxtzmbhfkjsogng99u5RL8JfKYeP71Gdj12hiCwr
dzO/4fAwsozZaVF7NGqkVGHDJamHfkEHksjv0y90dR5kDD5qi3X/54N3ZvrnlTxi
n8DEZi78RlQxdZUngCdC6ZaEF38bJzP5wjqN1deyZ9Lthb1Rx2BfaS5UbTomcN5r
EER70mH2Hf6tBxPnT60fZoHw74B02PtL7PrDk7Hpo0MzMWKliI8JEVO9iK9dUNCh
bVyLQ9zlWpcJ9uziGsycg7bA4yNUvdWXA3hS2H2LG2x1n6OnQj0IEi+veKT5sJsg
uD1yb3Pcxb6MRuRKaz0qPhUzsBpTlQfUot4ihdzQ9kTGy6M1/LIuNAjhezdNjp7M
tHiGQsoVbNtr1lHD31Pb
=r5oe
-----END PGP SIGNATURE-----

Re: Statistics Project Update #4

Zlatin Balevsky — 2012-05-21T23:46:52

Are these rate-limited in any way?  Do they obey some general
rate-limiting policies together with other messages?  IMHO maximum HTL
should be single-digits or you risk flooding.  Does fred have any
metrics collection system that would allow us to detect such flooding
events?


On Sat, May 19, 2012 at 5:46 PM, Steve Dougherty <steve-kVTqj8yhOEv2eFz/2MeuCQ< at >public.gmane.org> wrote:

Re: A better FAQ

Ian Clarke — 2012-05-20T16:30:09

Well, It's a service - not software.  It does raise a good question though,
whether we can extract the questions & answers should we decide to stop
using it.  I'll ask.

Ian.

On Sun, May 20, 2012 at 9:08 AM, Luke R. <gaming4jc2-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org> wrote:

Re: A better FAQ

Luke R. — 2012-05-20T14:08:50

It does look like a reaonably nice FAQ system, but it's ashame it's not open-source/GPL.

--- On Fri, 5/18/12, Ian Clarke <ian-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org> wrote:

From: Ian Clarke <ian-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org>
Subject: [freenet-dev] A better FAQ
To: "Discussion of development of development issues" <devl< at >freenetproject.org>
Date: Friday, May 18, 2012, 12:31 PM

A friend of mine has created this service: http://helpjuice.com/
It's basically a very smart FAQ that is capable of learning.  Our current FAQ, I think, is somewhat lackluster and intimidating.  My friend has offered to let us use HelpJuice for free - thoughts?  We should be able to integrate it into our site reasonably seamlessly.

Ian.

Statistics Project Update #4

Steve Dougherty — 2012-05-19T21:46:12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've finished a proof of concept for Metropolis-Hastings corrected
probes in Fred. If you are so inclined, please offer feedback on the
patches. [1] Metropolis-Hastings correction was described previously,
[2] and the probes are exposed over FCP. [3] An originating node starts
a probe request by specifying the type of result they're looking for,
and optionally a value for hopsToLive, which currently defaults to its
maximum of 50 if not specified. We will in practice initially use
something closer to 30. One can disable responding to any number of
result types on the Core settings page.

Possible types are:

BANDWIDTH - outgoing bandwidth limit.
BUILD - Freenet build number. (For instance, currently 1407.) Useful
        for measuring update propagation.
IDENTIFIER - endpoint identifier. Useful for improving estimates of
             network size and churn.
LINK_LENGTHS - differences in location between endpoint and each of
               endpoint's peers.
STORE_SIZE - size of datastore.
UPTIME - session uptime and the percentage of the past 48 hours during
         which the endpoint was up.

+/- up to 1% noise is added to bandwidth, link lengths, store size, and
uptime information in an attempt to make the information less
identifiable but still useful for analysis.

Bandwidth, link lengths, store size, and uptime are intended to improve
knowledge of the network so that any problems will hopefully become
apparent, or at the very least allow more detailed simulations which
more accurately reflect actual network conditions. This is with the
goal of implementing changes to improve network performance and
reliability.

Possible outcomes of the probes as implemented are:
    -non-propagated timeout
    -non-propagated disconnection
    -endpoint refusal for the result type
    -result from endpoint

Based on feedback in #freenet I've built a TODO list:

1. Access MHProbe from the callbacks, which are inner classes, via
MHProbe.this. This will mean no need to pass it in to use MHProbe as a
ByteCounter. Also because the callbacks are inner classes there is no
need for the horrible hack that is making pendingProbes public static.
2. If FOAF data for a peer is not available, ignore that peer.
3. Implement error messages so that resources can be freed quickly in
the event on an error:
    - next in chain disconnected
    - timeout
    - type unrecognized
    - FOAF disabled
4. If FOAF is completely disabled on a node, rather than ignore every
peer, leading to HTL decrementing until a local response, respond with
a "FOAF disabled" error message as above.
5. Add a node configuration option for a random (not based on noderef
like current probe and swap request identifier) identifier which is set
to a random value when at its default of -1.
6. Use a Gaussian distribution for randomNoise() because many tests
assume Gaussian noise, so why not?
7. Quantize things: instead of just adding noise, report bandwidth in
as 64-bit integer KiB and store size as 64-bit integer GiB.
8. Instead of separate identifier and uptime requests, allow requesting:
    - [ identifier, quantized noisy 7-day uptime percentage ]
    - [ noisy 7-day uptime percentage ]
    - [ noisy 48-hour uptime percentage ]
9. Set timeout as constant1 * HTL + constant2 to account for
probabilistic decrement at HTL = 1.

Next week I plan to address the TODO list and any more issues that come
up in the patch set, then submit it for merging into Fred once it has
been approved. After that, I will work on FCP library support for the
new probes, and update pyProbe to support gathering and analyzing the
new information. In the event that I finish these things I can work on
making the network simulator more flexible. Our target deployment date
is Friday the 25th May or the day after.

Thanks,
operhiem1

[1] https://github.com/thynix/fred-staging/tree/newProbes
[2] https://emu.freenetproject.org/pipermail/devl/2012-April/036363.html
[3] https://wiki.freenetproject.org/User:Operhiem1/MHProbeFCP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPuBSaAAoJECLJP19KqmFurkUQAJZbvpgctvsZxgppkRIW/ZOY
meNolQJCutEUHl8VFSdut/6ahRwJ3gfdCgOiF/GHcbEkZqm4S+Jna58Sz6E9WBSa
MfhjQ1dULutiE1vmXN/5v/vNwFYXlATAk2XK35IrUqbCorq7NZHQhSyn61j6fLdB
cGIBOV8GCRHd2rhFu4+oP9tECyoBbL7B9OqjI3AHPEuDEyvFVfuxfk6HDcOam+4Z
dzeecRUMU4T1wquOZ9l6sDTqe8m+RRuR++WHObQ/pI/n1s848HWTM0qs3Dzj3pIU
GNcgX4dbgH8yz3veInur2i6FSkM41IdwEbV3OHro+peOIxVmCJ3c6cEbkEYLQW/R
1mICM7+6CLNkzjrxSwiPNrhVYGGKrYy7F4YSDj2GWwwfwd5aQaxzCM5CO9+VaHWj
IL0b7TvRb2wiNnJWhKlnzNxosZMfQmgGGPskeIImcXUnKPuwy/SfGhEdNifVcsY9
nCF56vGQLmEK/PPdX4CjhWRHO20l2hle5qltapd0VZ9Fyq/pcxw9SiGEW6soBlnw
1gmyxLiWe5PSSic5QD/xtNLWXnPiqnt9gwyaJu0htfZxhB57usrfzivxJGOZbenK
t+QsBGTh8rv0qDHLu1MYKdz0zkGzMSNjNI5dAUs4xKptJ5wXeMsc8K8Ho+Ho7XcF
fxh2AN9VYZSUzTPRAb2L
=rwqn
-----END PGP SIGNATURE-----

A better FAQ

Ian Clarke — 2012-05-18T16:31:28

A friend of mine has created this service: http://helpjuice.com/

It's basically a very smart FAQ that is capable of learning.  Our current
FAQ, I think, is somewhat lackluster and intimidating.  My friend has
offered to let us use HelpJuice for free - thoughts?  We should be able to
integrate it into our site reasonably seamlessly.

Ian.

Re: Transport Plugins (Update)

Marco Schulze — 2012-05-16T08:44:47

Yes. Thank you.

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

Re: Transport Plugins (Update)

Chetan Hosmani — 2012-05-15T15:42:12

On Tue, May 15, 2012 at 8:39 PM, Marco Schulze
<marco.c.schulze-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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 :)

Re: Transport Plugins (Update)

Marco Schulze — 2012-05-15T15:09:47

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:

Re: Transport Plugins (Update)

Chetan Hosmani — 2012-05-15T09:20:28

On Tue, May 15, 2012 at 1:44 PM, Marco Schulze
<marco.c.schulze-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

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.

Re: Transport Plugins (Update)

Marco Schulze — 2012-05-15T08:14:45

Nice! Which transport plugins you are planning to implement?

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

Transport Plugins (Update)

Chetan Hosmani — 2012-05-15T07:13:33

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 :)

Re: Lantern

Arne Babenhauserheide — 2012-05-14T00:38:58

Am Sonntag, 13. Mai 2012, 13:22:57 schrieb Steve Dougherty:

I first wondered about your comment, but now I tried the program myself.

Who in his right mind writes an anonymizing program which tells Google that it 
wants to connect to your friends? Google of all the services… The only way to 
make that worse would be to use Facebook instead… 

Best wishes,
Arne

Re: Lantern

Arne Babenhauserheide — 2012-05-14T00:09:05

Am Sonntag, 13. Mai 2012, 17:38:45 schrieb Matthew Toseland:

Almost everybody I know who is serious about email uses a desktop app for 
that… 

Also I use identi.ca over choqok or emacs (identica-mode). 
And IRC over Quassel. Or emacs :) (erc)

When I’m at my own computer, no web-based program beats a desktop program.

My Parents use desktop-based programs, too.

Still I like the webinterface of freenet, because I can just send people links 
to http://127.… to show them how to configure something.

But a desktop program which uses freenet as backend could be quite a bit 
nicer. Creating a good desktop GUI is a hell of a lot of work, though.

Best wishes,
Arne
--
singing a part of the history of free software: 

- http://infinite-hands.draketo.de

_______________________________________________
Devl mailing list
Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ< at >public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl