Chetan Hosmani | 1 Apr 20:48 2012
Picon

GSOC 2012 Transport Plugin (Task on JCA)

Hello,

As an expected task for GSOC (discussed on IRC) I worked on the JCA
implementation for encryption.
Here is what I have done-

1. Created JCACipher implements Block Cipher.
2. Added negtype = 8
3. For negtype = 8 use new JCACipher object instead of new Rijndael object
4. Changed other methods in FNPPacketMangler to accept the new new link type

I needed to go through this paper to understand what JFK was all about
http://www.wisdom.weizmann.ac.il/~reingold/publications/jfk-tissec.pdf

What I am not sure of is that the method computeJFKsharedKey is used
by my cipher class too to generate the SecretKey required, but should
I use the JCA key generator to do so? That should not be a problem.

I am not sure if this is what nextgens had in mind.
But currently I have tested two nodes running in darknet mode, and
they were able to connect to each other and send messages. Also I used
the debugger to see if negtype = 8 was present.

I also ran another old node for which negtype=7 worked normally
(backward compatible). I hope this is what you were expecting. Here is
the patch, but I suppose you want me to send a pull request? I ll do
that too.

Thank you,
Chetan
(Continue reading)

Matthew Toseland | 3 Apr 00:03 2012
Picon

Re: GSOC 2012 Transport Plugin (Task on JCA)

On Sunday 01 Apr 2012 19:48:43 Chetan Hosmani wrote:
> Hello,
> 
> As an expected task for GSOC (discussed on IRC) I worked on the JCA
> implementation for encryption.
> Here is what I have done-
> 
> 1. Created JCACipher implements Block Cipher.
> 2. Added negtype = 8
> 3. For negtype = 8 use new JCACipher object instead of new Rijndael object
> 4. Changed other methods in FNPPacketMangler to accept the new new link type
> 
> I needed to go through this paper to understand what JFK was all about
> http://www.wisdom.weizmann.ac.il/~reingold/publications/jfk-tissec.pdf
> 
> What I am not sure of is that the method computeJFKsharedKey is used
> by my cipher class too to generate the SecretKey required, but should
> I use the JCA key generator to do so? That should not be a problem.

Don't know, I presume JCA uses some sort of Diffie-Hellman key generator? JFK is a variant on DH.
> 
> I am not sure if this is what nextgens had in mind.
> But currently I have tested two nodes running in darknet mode, and
> they were able to connect to each other and send messages. Also I used
> the debugger to see if negtype = 8 was present.
> 
> I also ran another old node for which negtype=7 worked normally
> (backward compatible). I hope this is what you were expecting. Here is
> the patch, but I suppose you want me to send a pull request? I ll do
> that too.
(Continue reading)

Matthew Toseland | 3 Apr 00:04 2012
Picon

Re: Logging in Fred

On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >>
> >> In 'log.info("Random message: %s", obj.toString())' evaluating 'obj.toString()' was what caused
issues, not recycling it, or so I believe to remember.
> >
> > You don't need to call obj.toString() before calling log() - just pass the object itself. Then the only
overheads are:
> > 1) Calling the function, including passing the arguments - which hopefully will be optimised to be on
some stack (but the code might not have been JITted yet).
> > 2) Looking up whether it needs to be logged.
> >
> 
> 3) Autoboxing because you cannot pass a primitive if the argument is
> Object without creating a <? extends Number>.  Small ranges of
> Char/Short/Integer/Long values are cached, anything outside those will
> end up creating garbage if the shouldLog predicate evaluate true even
> once.

Will it still autobox them if they are on the stack, and never used?
> 
> ... but you could get around this problem by adding many log functions
> with different signatures that take primitives.  The burden then falls
> on the programmer to find the appropriate function at each call site.
_______________________________________________
Devl mailing list
Devl@...
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Matthew Toseland | 3 Apr 00:05 2012
Picon

Re: Logging subsystem rewrite

On Saturday 31 Mar 2012 03:53:09 Zlatin Balevsky wrote:
> >
> > But we use a static logging API anyway, and this works adequately well. I have debugged stuff largely
through logs in multi-node simulators, I generally rely on the thread name to identify the node (e.g. the
UDP receive and send thread include the port number in the thread name).
> >
> 
> It could become an issue when trying to reproduce rare concurrency
> bugs that require running tests in a loop until they fail.  The
> smaller the synchronization overhead of the logging subsystem, the
> less noise you introduce in the simulation as you increase
> parallelism.  It also runs faster and you reproduce the bug sooner.

Yes, I have already pointed out why we log millisecond precision datestamps, and why it doesn't make sense
to actually write to the log on the thread creating the log line.
_______________________________________________
Devl mailing list
Devl@...
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Matthew Toseland | 3 Apr 00:06 2012
Picon

Re: Logging subsystem rewrite

On Friday 30 Mar 2012 22:28:09 Marco Schulze wrote:
> On 30-03-2012 13:28, Matthew Toseland wrote:
> > On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:
> >> Working (but incomplete) code is available  <at> 
> >> https://github.com/Heiral/fred-staging/tree/logger++
> > I'm keeping out of this for now, it should go in if it:
> > - Simplifies the code.
> Testing is centralized inside Log.isLoggable() and Log.write(). No 
> callbacks or registering is needed, and mistakes in current code is 
> mitigated (i.e. testing for one log level, and actually logging in 
> another). IMHO, cutting ~5000 lines from the code, and ~200k from the 
> jar speaks for itself.
> 
> > - Does not significantly reduce performance.
> Until fred actually uses lazy toString() in log calls, that'll be 
> unknown. Lazyness already works, though.
> 
> > - Does not significantly reduce debuggability (i.e. we need to be able to use wildcards).
> In to do list.
> 
> > - Reacts quickly enough (~1 second) to config changes.
> All but adding per-class filtering should be quick enough.
> 
> > - Does not create a locking hotspot.
> Only the OutputStream is locked. Mitigated by possible async option.

Async is essential, otherwise you have the mother of all lock contention problems: if you don't buffer it, a
system call; if you do buffer it, best case is lock contention, worst case is a system call.

So AFAICS we need to keep most of the current FileLoggerHook. :|
(Continue reading)

Matthew Toseland | 3 Apr 00:07 2012
Picon

Re: Coding standards

On Friday 30 Mar 2012 19:34:02 Juiceman wrote:
> On Mar 30, 2012 1:12 PM, "Matthew Toseland" <toad@...>
> wrote:
> >
> > On Sunday 25 Mar 2012 19:33:45 Juiceman wrote:
> > > On Mon, Mar 19, 2012 at 6:13 PM, Marco Schulze
> > > <marco.c.schulze@...> wrote:
> > > > May I add a vote to standardise indentation? This mess of spaces with
> tabs
> > > > really bugs me.
> > > >
> > >
> > > Assuming tabs 8 spaces wide the current code yields 9,187 lines with
> > > warnings about being longer than 120 chars.
> >
> > Doesn't eclipse use 4 space tabs by default?
> >
> 
> I think so, but that is not what our wiki says is freenets standard
> 
Maybe the wiki is wrong? :) All in favour of 8 space tabs?
_______________________________________________
Devl mailing list
Devl@...
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Evan Daniel | 3 Apr 00:31 2012
Picon

Re: Coding standards

I'm in favor, and I suspect I'm the author of that line :)

I also don't actually care that much, so feel free to change it to 4.

On Apr 2, 2012 6:07 PM, "Matthew Toseland" <toad-EI5O+8PHWbJeeLb3ft/vUmD2FQJk+8+b@public.gmane.org> wrote:

On Friday 30 Mar 2012 19:34:02 Juiceman wrote:
> On Mar 30, 2012 1:12 PM, "Matthew Toseland" <toad <at> a...

Maybe the wiki is wrong? :) All in favour of 8 space tabs?

_______________________________________________
Devl mailing list
Devl-RdDMkVZAZeuJnvDnx1genB2eb7JE58TQ@public.gmane.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
Devl@...
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Zlatin Balevsky | 3 Apr 03:26 2012
Picon

Re: Logging in Fred

On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
<toad@...> wrote:
> On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
>> >>
>> >> In 'log.info("Random message: %s", obj.toString())' evaluating 'obj.toString()' was what caused
issues, not recycling it, or so I believe to remember.
>> >
>> > You don't need to call obj.toString() before calling log() - just pass the object itself. Then the only
overheads are:
>> > 1) Calling the function, including passing the arguments - which hopefully will be optimised to be on
some stack (but the code might not have been JITted yet).
>> > 2) Looking up whether it needs to be logged.
>> >
>>
>> 3) Autoboxing because you cannot pass a primitive if the argument is
>> Object without creating a <? extends Number>.  Small ranges of
>> Char/Short/Integer/Long values are cached, anything outside those will
>> end up creating garbage if the shouldLog predicate evaluate true even
>> once.
>
> Will it still autobox them if they are on the stack, and never used?

If the isDebuggable predicate never evaluates true, then it's not a
problem.  But if it evaluates true even once for the lifetime of the
loaded class it will create these objects.  It's a quirk of current
hotspot jvm which will not affect production deployments but will
affect the developer: turning on debug logging for one class will
cause all primitives in all log statements to be instantiated.  I had
some sample code earlier in the thread.
Chetan Hosmani | 3 Apr 05:48 2012
Picon

Re: GSOC 2012 Transport Plugin (Task on JCA)

Okay I ll read about what JCA uses. JCA actually supports several
variations and algorithms.

Yes I have a node running that connects to similar new nodes using
negtype = 8 (which is JCA)
and it also connects to old nodes using the previous negotiation types.
On the surface it runs exactly the way it used to. Atleast I have not
seen any difference.

On Tue, Apr 3, 2012 at 3:33 AM, Matthew Toseland
<toad@...> wrote:
> On Sunday 01 Apr 2012 19:48:43 Chetan Hosmani wrote:
>> Hello,
>>
>> As an expected task for GSOC (discussed on IRC) I worked on the JCA
>> implementation for encryption.
>> Here is what I have done-
>>
>> 1. Created JCACipher implements Block Cipher.
>> 2. Added negtype = 8
>> 3. For negtype = 8 use new JCACipher object instead of new Rijndael object
>> 4. Changed other methods in FNPPacketMangler to accept the new new link type
>>
>> I needed to go through this paper to understand what JFK was all about
>> http://www.wisdom.weizmann.ac.il/~reingold/publications/jfk-tissec.pdf
>>
>> What I am not sure of is that the method computeJFKsharedKey is used
>> by my cipher class too to generate the SecretKey required, but should
>> I use the JCA key generator to do so? That should not be a problem.
>
> Don't know, I presume JCA uses some sort of Diffie-Hellman key generator? JFK is a variant on DH.
>>
>> I am not sure if this is what nextgens had in mind.
>> But currently I have tested two nodes running in darknet mode, and
>> they were able to connect to each other and send messages. Also I used
>> the debugger to see if negtype = 8 was present.
>>
>> I also ran another old node for which negtype=7 worked normally
>> (backward compatible). I hope this is what you were expecting. Here is
>> the patch, but I suppose you want me to send a pull request? I ll do
>> that too.
>
> So you have a node running connecting to at least one node via the new protocol, and to others via the old protocol?
>>
>> Thank you,
>> Chetan
Israel Leiva | 3 Apr 09:01 2012
Picon

GsoC - FCP Library

Hello,

I'm a Computer Science Engineering student at Federico Santa María 
Technical University, Chile. As the title of this email suggests, I 
would like to apply to Freenet for the Google summer of Code. I've read 
the Ideas Page for this year and I'm interested in implementing "Good 
FCP libraries in more languages". This is mainly because I'm not a good 
Java programmer and also because I believe a good FCP implementation may 
hopefuly encourage the development of new tools that interact to Freenet 
by developers that prefer other languages rather than Java. My main 
suggestion is to fully improve/rewrite the Perl FCP Module [1], given 
that it hasn't been updated in almost two years, there are few methods 
implemented and I personally think that the code is pretty messy. You 
can see my Perl work in [2]. I'm also willing to implemente a pure C 
(not C++) FCP library in case you don't like the former idea.

Having said that, may I ask, is this idea suitable for Freenet developer 
community? what are your thoughts on this?

Thank you in advance.

References:
[1] http://search.cpan.org/~mlehmann/AnyEvent-FCP-0.3/FCP.pm
[2] http://search.cpan.org/~ilv/

Best regards.
--
Israel Leiva

Gmane