[freenet-dev] JCA patch
Hi Sorry but I didn't understand what you meant by (on github) ->This is actually using 256/256 Rijndael, the JVM appears to allow it. Is the JCA encryption same as Rijndael or my code is still using Rijndael instead of JCA? I tested this and JCA was being called. If its same as Rijndael I get what you mean, that a new negtype is not needed. Also I should actually test it with (256, 128). ->probably require switching to the standard CFB mode I am already using JCA in AES CFB mode as the default. Though I am not sure what happens when key = block = 256. I ll check that. I will also try without Rijndael (probably modify Rijndael.java file itself to use JCA, as a temporary hack?). If it works I will benchmark it and then let you know. The initialisation is needed each time for choosing the mode - encrypt or decrypt. But I can initialise two ciphers in JCACipher, one for encryption and another for decryption. So that would make it faster, probably. I ll test each of them for performance and post them here. Thank you On Thu, Apr 5, 2012 at 5:28 PM, Matthew Toseland wrote: > On Tuesday 03 Apr 2012 22:01:40 Chetan Hosmani wrote: >> Hello, >> >> nextgens as you wanted some changes I have implemented them. I have >> sent a pull request to freenet:next. >> Here is the patch. > > Cool. > > It's here: > https://github.com/freenet/fred-staging/pull/88 > > There was some confusion about this. From your code it appears that we can > just specify a 256 bit block size and the standard code will work. In which > case, the new encryption is exactly the same as the old: 256-bit key, 256-bit > block size, with PCFB mode on top. So you don't need the new negType. Please > test this. If it works, you can use it everywhere in the code, and get rid of > Rijndael, which would be pretty cool. But if so, please benchmark it first: > As I mentioned, are you sure you need to initialise the cipher for each > block? If it's slower in software then we need to keep the old version and > only use the JCA version on startup ... > > I suspect that 256-bit block size isn't hardware accelerated, and certainly > it isn't the standard. So the original plan was to switch to standard AES > (256-bit key, 128-bit block size), which would have required using CFB (which > the JCA probably implements). > > This isn't a criticism anyway. If we can switch to the JVM's AES > implementation without even any back compatibility issues, and without a > performance loss, that would be really nice. >> >> Also wanted some opinion on the idea "Switch from the current code to >> JCA". Since I have been working and reading on this, I thought I ll >> send in a proposal for this task too. Any pointers or suggestions will >> be helpful. I will make a rough draft and mail that too, though there >> is hardly any time left for discussion. > > Well, the above suggests it'd be a fairly small project, although we'd want > to switch some algorithms, such as the above, at the same time. >> >> Thank you
[freenet-dev] GsoC - FCP Library
El 05/04/12 08:09, Matthew Toseland escribi?: > Anyone interested in mentoring this? I really don't think I'm the right > person to mentor a perl project. I finished the proposal: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/ilv/1 Looking forward for your comments. Regards. -- Israel Leiva
[freenet-dev] Logging subsystem rewrite
>>
>> Any patch with lazy evaluation will not cause problems in the "normal"
>> case but will affect debugging Fred because turning on debug log level
>> for a single class will cause all lazy parameters everywhere to be
>> created.
Before someone calls me out on this one I this is how you can use lazy
evaluation without garbage on hotspot jvms. The statement becomes
getLog().log( ) and the predicate goes in the getter.
= CallSiteJitting.java =
public class CallSiteJitting {
static interface Logger {
void log(Object ar1, Object ar2);
}
static class MuteLogger implements Logger {
public void log(Object ar1, Object ar2){}
}
static class RealLogger implements Logger {
static long sideEffect;
public void log(Object ar1, Object ar2) {
sideEffect += ar1.hashCode();
sideEffect += ar2.hashCode();
}
}
private static final Logger mute = new MuteLogger();
private static final Logger real = new RealLogger();
private static boolean once;
private static Logger getLog() {
if (!once) {
once = true;
System.out.println("real logging once");
// if you return real every time lots of
// garbage collections happen
return real;
}
return mute;
}
public static void main(String []ar) throws Exception {
for (long l = 0; l < Long.MAX_VALUE; l++) {
getLog().log(new Object(), new Object());
}
System.out.println(RealLogger.sideEffect);
}
}
= end CallSiteJitting.java
[freenet-dev] bigint-gnu-gmp and bigint7
On 05/04/12 19:32, Ximin Luo wrote: > I haven't looked at them for a while, but if I remember right: > > bigint7: benchmark the performance of java 7 biginteger > bigint-gnu-gmp: benchmark the performance of gmp-java's biginteger > > gmp-java is my take on NativeBigInteger: > > https://github.com/infinity0/mozilla-gnome-keyring fuck sakes, clipboard fail. right one: https://github.com/infinity0/gmp-java > > it performs better than it, and is simpler to build than all of that native > crap, and allows us to get rid of the mess that is CPUInformation as well. > > I suggest we migrate to it, but only after we split off freenet-ext.jar > > (There's a lot of things that depend on this split, we need to get this done > with high priority.) > > X > > On 05/04/12 15:29, Matthew Toseland wrote: >> What is the purpose of the bigint-gnu-gmp branch? And bigint7? >> >> >> >> ___ >> Devl mailing list >> Devl at freenetproject.org >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/f3b7555b/attachment.pgp>
[freenet-dev] bigint-gnu-gmp and bigint7
I haven't looked at them for a while, but if I remember right: bigint7: benchmark the performance of java 7 biginteger bigint-gnu-gmp: benchmark the performance of gmp-java's biginteger gmp-java is my take on NativeBigInteger: https://github.com/infinity0/mozilla-gnome-keyring it performs better than it, and is simpler to build than all of that native crap, and allows us to get rid of the mess that is CPUInformation as well. I suggest we migrate to it, but only after we split off freenet-ext.jar (There's a lot of things that depend on this split, we need to get this done with high priority.) X On 05/04/12 15:29, Matthew Toseland wrote: > What is the purpose of the bigint-gnu-gmp branch? And bigint7? > > > > ___ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/adcdb016/attachment.pgp>
Re: [freenet-dev] GsoC - FCP Library
El 05/04/12 08:09, Matthew Toseland escribió: Anyone interested in mentoring this? I really don't think I'm the right person to mentor a perl project. I finished the proposal: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/ilv/1 Looking forward for your comments. Regards. -- Israel Leiva ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] GSoC 2012 Transport Plugin
Thank you so much toad. Its very detailed and I ll need to go through it thoroughly. Also I am not sure this is relevant, but I did get a mail from a "stranger" who happened to be going through the archives and decided to send me an opinion. I thought it's best if we discussed here. I requested the person to participate here, and will hopefully do so. On Wed, Apr 4, 2012 at 1:16 PM, cagsm wrote: Hello GSOC participant, I am not on the Freenet mailing list, but I read the archvies and I have seen an interesting discussion on Freenet (insinde Freenet, within the FMS communications tool, in the Freenet forum there). Some fellow FMS/Freenet user proposed to look at the open source project "udt" (Sourceforge), that is essentially an intelligent and very robust and proven way to do udp communications. If you are already re-implementing the old raw udp way of Freenet transport layers and modularizing it, which is needed due to compatibility reasons as another fellow FMS/Freenet participant (bombe I think) pointed out, then it would be probably better to migrate away from the raw udp way to the udt way in the long run, before attempting the next real transport plugin (tcp). Please consider into looking at the udt project and making use of it. Would be very glad if you could include it in Freenet. http://udt.sourceforge.net/ On Thu, Apr 5, 2012 at 6:21 PM, Matthew Toseland wrote: > On Wednesday 04 Apr 2012 07:15:26 Chetan Hosmani wrote: >> Hello, >> >> With only three days left for the deadline of submission of proposals >> I was hoping I could get some suggestions on my proposal. >> This is my only proposal. I am also working on another proposal to >> Freenet itself (implementing JCA). >> Any suggestions will be really helpful. >> >> The proposal can viewed publicly here- >> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/chetanhosmani/1 >> >> Apart from adding references and links, this is the final version. >> Please leave comments. > > The introduction is good. > > IMHO it's not grouped *that* tightly: exactly what does NodeCrypto do that is > low level? The key classes afaics are NewPacketFormat, UdpSocketHandler, > FNPPacketMangler. IMHO UdpSocketHandler and SocketHandler in general already > effectively separate the actual socket implementation. Of course pretty much > all of it assumes a packet transport, e.g. PacketSender constantly loops over > peers to send packets to them. > > We have a structure for messages that are ready to send, PeerMessageQueue on > PeerNode. > > However I agree that the messages-in-flight structure is too tightly > integrated with NewPacketFormat, in NewPacketFormat itself and > NewPacketFormatKeyContext. I don't know whether this structure will be > adequate for *all* transports; it's likely to be overkill for TCP-based > transports, but for some packet based formats with bigger packets and longer > latencies it might be too limited? A single messages in flight queue makes > sense though for robustness, in fact given we assume reliable delivery (or > throw an exception), it's essential. But I'm not sure how you would manage > resends for multiple transports... Wouldn't they have separate timers etc? > Clearly we would want to send a message over another transport if one dies, > or persistently can't send it ... > > NewPacketFormat contains the queue of messages in flight. > NewPacketFormatKeyContext contains the data on *packets* in flight. TCP > presumably won't have packets, but will need to group messages and HMAC them, > and the two streams aren't necessarily perfectly synchronised so we'd > probably want some sort of sequence number acknowledgements ... > > The OldPacketFormat/PacketTracker code can probably be got rid of now, people > have had plenty of time to upgrade. > > If it's acceptable for TCP, then I'm quite happy for you to factor it out > into another class. Rewriting it yet again would be a lot of work for no > obvious advantage, but if you have a clear set of reasons for doing so that > would be interesting. > > Re multiple connections to a single peer, this is all in PeerNode. It can > receive messages from any transport (handle*), it has a queue which is read > e.g. when PacketSender asks it to prepare a packet, but a significant part of > the complexity of the UDP transport results from hacks related to various > failure modes in session setup (I believe we spoof a restart in some cases). > As does code elsewhere, e.g. there is a single throttle used by PacketSender > for a PeerNode. > > To implement UDP as a transport plugin, you will need to implement the > transport plugin API *first*, because it is an unreliable packet transport. > You will need to refactor crypto support for the plugin to be where it needs > to be. But it's the same crypto; the main difference is we can handle > multiple connections to the same peer over different IP addresses more > cleanly. > > Then you will need to implemen
[freenet-dev] Logging subsystem rewrite
> ?If your 'solution' is trading 'jar > ?size' and 'readability' against run-time performance (for the common > ?case assuming logNORMAL), we won't merge it. Freenet is slow enough > ?as is. Any patch with lazy evaluation will not cause problems in the "normal" case but will affect debugging Fred because turning on debug log level for a single class will cause all lazy parameters everywhere to be created. Imagine you're trying to reproduce a rare bug and have turned on one or two debug statements - because of lazy evaluation your jvm will garbage collect much more often and you may never reproduce the bug. This is valid for current generation jvms. > > Hint: your doing it wrong, the one way to make it faster and nicer is to > ?use dependancy injection > DI is generally great but it doesn't solve the problem of "ugly predicate". You're better off looking at some bytecode weaving techniques like aspects. Combined with DI they can make the code very clean.
Re: [freenet-dev] Logging subsystem rewrite
>>
>> Any patch with lazy evaluation will not cause problems in the "normal"
>> case but will affect debugging Fred because turning on debug log level
>> for a single class will cause all lazy parameters everywhere to be
>> created.
Before someone calls me out on this one I this is how you can use lazy
evaluation without garbage on hotspot jvms. The statement becomes
getLog().log( ) and the predicate goes in the getter.
= CallSiteJitting.java =
public class CallSiteJitting {
static interface Logger {
void log(Object ar1, Object ar2);
}
static class MuteLogger implements Logger {
public void log(Object ar1, Object ar2){}
}
static class RealLogger implements Logger {
static long sideEffect;
public void log(Object ar1, Object ar2) {
sideEffect += ar1.hashCode();
sideEffect += ar2.hashCode();
}
}
private static final Logger mute = new MuteLogger();
private static final Logger real = new RealLogger();
private static boolean once;
private static Logger getLog() {
if (!once) {
once = true;
System.out.println("real logging once");
// if you return real every time lots of
// garbage collections happen
return real;
}
return mute;
}
public static void main(String []ar) throws Exception {
for (long l = 0; l < Long.MAX_VALUE; l++) {
getLog().log(new Object(), new Object());
}
System.out.println(RealLogger.sideEffect);
}
}
= end CallSiteJitting.java
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Logging subsystem rewrite
On Thursday 05 Apr 2012 23:49:04 Zlatin Balevsky wrote:
> > If your 'solution' is trading 'jar
> > size' and 'readability' against run-time performance (for the common
> > case assuming logNORMAL), we won't merge it. Freenet is slow enough
> > as is.
>
> Any patch with lazy evaluation will not cause problems in the "normal"
> case but will affect debugging Fred because turning on debug log level
> for a single class will cause all lazy parameters everywhere to be
> created. Imagine you're trying to reproduce a rare bug and have
> turned on one or two debug statements - because of lazy evaluation
> your jvm will garbage collect much more often and you may never
> reproduce the bug. This is valid for current generation jvms.
>
> > Hint: your doing it wrong, the one way to make it faster and nicer is to
> > use dependancy injection
>
> DI is generally great but it doesn't solve the problem of "ugly
> predicate". You're better off looking at some bytecode weaving
> techniques like aspects. Combined with DI they can make the code very
> clean.
Whatever the interface is, the Right Way is to introduce the predicates at run
time. (Assuming that doesn't affect debuggability and doesn't significantly
slow loading). It may be possible to do this with the bytecode manipulation
library provided by db4o, which it uses for optimising native queries (queries
expressed as function(object) { return true if we want it }). On the other hand
it's quite heavyweight, which is why we don't generally use native queries...
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
Re: [freenet-dev] Logging subsystem rewrite
> If your 'solution' is trading 'jar > size' and 'readability' against run-time performance (for the common > case assuming logNORMAL), we won't merge it. Freenet is slow enough > as is. Any patch with lazy evaluation will not cause problems in the "normal" case but will affect debugging Fred because turning on debug log level for a single class will cause all lazy parameters everywhere to be created. Imagine you're trying to reproduce a rare bug and have turned on one or two debug statements - because of lazy evaluation your jvm will garbage collect much more often and you may never reproduce the bug. This is valid for current generation jvms. > > Hint: your doing it wrong, the one way to make it faster and nicer is to > use dependancy injection > DI is generally great but it doesn't solve the problem of "ugly predicate". You're better off looking at some bytecode weaving techniques like aspects. Combined with DI they can make the code very clean. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] bigint-gnu-gmp and bigint7
What is the purpose of the bigint-gnu-gmp branch? And bigint7? -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/9a363f61/attachment.pgp>
[freenet-dev] Space stripping
Re 2d011ed5bd2f59b0a1a90383566b2f62378245b8 (origin/accept-linewrapped-keys): IMHO we should only try stripping spaces after we have failed to parse without stripping them. So it should be an option on decode(), and FreenetURI should try with and without. -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/dc57213b/attachment.pgp>
[freenet-dev] Can we just put the new wrapper jar on the classpath?
On Tuesday 03 Apr 2012 20:57:08 Ximin Luo wrote: > On 03/04/12 19:57, Matthew Toseland wrote: > > Nextgens is convinced that many of the problems users have installing on > > Windows are due to firewalls blocking the localhost connection between the > > wrapper binary and the JVM running Freenet. The usual solution proposed is > > to split up freenet-ext.jar, which infinity0 has been working on. Can we do > > a quick fix though? Just introduce the new wrapper jar on the classpath in > > new installs, so that it overrides the wrapper classes in freenet-ext.jar? > > The main difficulty appears to be update.cmd - on Windows, it will clobber > > wrapper.conf in some circumstances, in which case it could revert it to a > > version without the new wrapper.jar and thus break it. > > > > See bug: https://bugs.freenetproject.org/view.php?id=4075 > > How does splitting up freenet-ext.jar help with "not creating a localhost > socket"? > > i.e. can you explain the solution in more detail. Wrapper 3.4 allows you to use a named pipe instead, from a config option in wrapper.conf. This avoids firewall issues and so hopefully results in a more reliable setup on Windows. -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/533f4c74/attachment.pgp>
[freenet-dev] GSoC 2012 Transport Plugin
tly synchronised so we'd > > probably want some sort of sequence number acknowledgements ... > > > > The OldPacketFormat/PacketTracker code can probably be got rid of now, > > people have had plenty of time to upgrade. > > > > If it's acceptable for TCP, then I'm quite happy for you to factor it out > > into another class. Rewriting it yet again would be a lot of work for no > > obvious advantage, but if you have a clear set of reasons for doing so that > > would be interesting. > > > > Re multiple connections to a single peer, this is all in PeerNode. It can > > receive messages from any transport (handle*), it has a queue which is read > > e.g. when PacketSender asks it to prepare a packet, but a significant part > > of the complexity of the UDP transport results from hacks related to > > various failure modes in session setup (I believe we spoof a restart in > > some cases). As does code elsewhere, e.g. there is a single throttle used > > by PacketSender for a PeerNode. > > > > To implement UDP as a transport plugin, you will need to implement the > > transport plugin API *first*, because it is an unreliable packet transport. > > You will need to refactor crypto support for the plugin to be where it > > needs to be. But it's the same crypto; the main difference is we can handle > > multiple connections to the same peer over different IP addresses more > > cleanly. > > > > Then you will need to implement connection setup for stream-based > > transports, as well as the basic plugin API, and the driver code (I assume > > a stream-based transport will present a pair of InputStream/OutputStream?). > > Connection setup should be fairly similar to the existing code. Whether you > > want to support sending parts of messages like we do with UDP is unclear; > > see above. > > > > IMHO multiple connections between the same two nodes are an essential part > > of the GSoC, if only because we will want nodes to expose more than one > > transport, so that they can connect to the maximum possible range of other > > nodes. So it will be possible that two connection setups complete > > simultaneously. "Just close one" is not anywhere near as simple as you > > might think, from my experience with UDP ... > > > > I agree that HTTP etc is optional though. > > > > Obviously NodeCrypto should have a set of transport addresses, not just the > > one port number for UDP. > > > > I agree that you will need a different SocketHandler base class for > > stream-based transports. > > > > Ideas on where the boundaries lie: > > - Clearly the packet format is specific to a particular transport type. It > > will be different for packets vs streams. > > - Crypto setup for streams could be the same algorithm, but even if it is, > > it may not share the same code. The current code is designed for lossy > > packets, whereas a much simpler control flow is possible for a stream. > > Authentication is obviously different: A packet has an HMAC, whereas for a > > stream you can use a self-authenticating cipher or you can group messages > > in a cluster (with a sequence number for ack's) and then give an HMAC. IMHO > > the latter is better. > > - Retransmission logic will need to be different for each transport, but > > the messages in flight must be shared with failover. This is going to be > > tricky as I explained above. > > - The queue of messages that have not yet been sent at all is common. > > > > IMHO it should be possible to keep more or less the same crypto, packet > > format, connection setup and message queueing for UDP-based connections, so > > back compatibility shouldn't be a problem - but if there are reasons for a > > totally new message queueing system, please post them! > > > > Obviously you need to ensure that only the code that is absolutely > > essential is in the actual socket handler class. Stuff that is related to > > decoding messages etc should be elsewhere - UdpSocketHandler should simply > > connect a UDP socket to the standard crypto/etc code. It should be really > > simple. Ideally this would be a separate class (rather than inheriting), so > > it can more easily be passed in by a plugin. > > > > We don't need an actual plugin at this point, just a clean API. So TCP can > > be built-in IMHO, although you could build it as a plugin if you want to > > demonstrate the whole thing. > > > > Regular updates are essential. You will need to work closely with a > > competent mentor (probably nextgens), and he will regularly review your > > commits; saving them up for a month and then "dropping a bomb" is very > > anti-social. > > > > Re documentation, try to javadoc stuff when you are creating new big > > classes. Not that we all do all the time. This will help in review and in > > not getting confused later. > > > > Generally looks good, though ultimately whether you are accepted is up to > > your mentor (and google). I will try to help out where I can but I don't > > have the time to be a mentor. > > -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/e3668fee/attachment.pgp>
[freenet-dev] GSoC 2012 Transport Plugin
viously different: A packet has an HMAC, whereas for a stream you can use a self-authenticating cipher or you can group messages in a cluster (with a sequence number for ack's) and then give an HMAC. IMHO the latter is better. - Retransmission logic will need to be different for each transport, but the messages in flight must be shared with failover. This is going to be tricky as I explained above. - The queue of messages that have not yet been sent at all is common. IMHO it should be possible to keep more or less the same crypto, packet format, connection setup and message queueing for UDP-based connections, so back compatibility shouldn't be a problem - but if there are reasons for a totally new message queueing system, please post them! Obviously you need to ensure that only the code that is absolutely essential is in the actual socket handler class. Stuff that is related to decoding messages etc should be elsewhere - UdpSocketHandler should simply connect a UDP socket to the standard crypto/etc code. It should be really simple. Ideally this would be a separate class (rather than inheriting), so it can more easily be passed in by a plugin. We don't need an actual plugin at this point, just a clean API. So TCP can be built-in IMHO, although you could build it as a plugin if you want to demonstrate the whole thing. Regular updates are essential. You will need to work closely with a competent mentor (probably nextgens), and he will regularly review your commits; saving them up for a month and then "dropping a bomb" is very anti-social. Re documentation, try to javadoc stuff when you are creating new big classes. Not that we all do all the time. This will help in review and in not getting confused later. Generally looks good, though ultimately whether you are accepted is up to your mentor (and google). I will try to help out where I can but I don't have the time to be a mentor. -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/67528bc3/attachment.pgp>
[freenet-dev] GsoC - FCP Library
El 05/04/12 08:09, Matthew Toseland escribi?:
> On Thursday 05 Apr 2012 06:40:58 Israel Leiva wrote:
>
>> Alright. Here is a simple demo of what I thought for the FCP2 Perl library.
>>
>> http://csrg.cl/~ileiva/gsoc/
>>
>> The directory includes (all files were renamed to .txt so you could read
>> it online):
>>
>> client.pl.txt-- Simple use of FCP2 Perl library
>> Freenet/FCP2.pm.txt -- FCP2 Perl Module (demo)
>> Freenet/FCP2/Message.pm.txt -- Message interface for FCP2 Module (demo)
>> Freenet/FCP2.pod.txt -- Documentation for FCP2.pm
>> Freenet/FCP2-Message.pod.txt -- Documentation for FCP2/Message.pm Module
>> (demo)
>> output.txt -- Results for the use of client.pl
>> readme.txt -- You should read this if you want to try this Library at
>> your own
>> Freenet-FCP2-demo.tar.gz -- All the files
>>
>> Note: Documentation files should be readed with _perldoc_ . Look at the
>> readme.txt for more details.
>>
>> I'm open to suggestions/ideas/comments.
> Anyone interested in mentoring this? I really don't think I'm the right
> person to mentor a perl project.
>
IMHO there is no need to have an advanced knowledge in Perl to supervise
such a project. I tried to make the demo as OO as I could so even
someone familiar with PHP or similar could understand it. As I see it,
one option is that the progress on a new FCP Library could be
reflected/measured by a well documentation process (of the Library).
I believe times where Perl was an encryption method are far behind. Just
to give an example, I don't think this is a 'write-only' script (as
someone said on IRC):
$ans = $client->hello();
print $ans->get('Version');
print "\n";
Anyway, I hope someone could have the time to mentor this, I'm very
excited about it.
Best Regards.
--
Israel Leiva
[freenet-dev] GsoC - FCP Library
On Thursday 05 Apr 2012 06:40:58 Israel Leiva wrote: > El 03/04/12 11:08, Matthew Toseland escribi?: > > The python module is used in some important tools, so in principle > > this is a good thing. I'm not competent to review Perl code, maybe we > > can find somebody who is though. Generally we don't accept prior work > > as proof that a student can code, but if it's freenet-specific then > > maybe ... > > Alright. Here is a simple demo of what I thought for the FCP2 Perl library. > > http://csrg.cl/~ileiva/gsoc/ > > The directory includes (all files were renamed to .txt so you could read > it online): > > client.pl.txt-- Simple use of FCP2 Perl library > Freenet/FCP2.pm.txt -- FCP2 Perl Module (demo) > Freenet/FCP2/Message.pm.txt -- Message interface for FCP2 Module (demo) > Freenet/FCP2.pod.txt -- Documentation for FCP2.pm > Freenet/FCP2-Message.pod.txt -- Documentation for FCP2/Message.pm Module > (demo) > output.txt -- Results for the use of client.pl > readme.txt -- You should read this if you want to try this Library at > your own > Freenet-FCP2-demo.tar.gz -- All the files > > Note: Documentation files should be readed with _perldoc_ . Look at the > readme.txt for more details. > > I'm open to suggestions/ideas/comments. Anyone interested in mentoring this? I really don't think I'm the right person to mentor a perl project. > > Best Regards. -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/deabbb30/attachment.pgp>
[freenet-dev] JCA patch
On Tuesday 03 Apr 2012 22:01:40 Chetan Hosmani wrote: > Hello, > > nextgens as you wanted some changes I have implemented them. I have > sent a pull request to freenet:next. > Here is the patch. Cool. It's here: https://github.com/freenet/fred-staging/pull/88 There was some confusion about this. From your code it appears that we can just specify a 256 bit block size and the standard code will work. In which case, the new encryption is exactly the same as the old: 256-bit key, 256-bit block size, with PCFB mode on top. So you don't need the new negType. Please test this. If it works, you can use it everywhere in the code, and get rid of Rijndael, which would be pretty cool. But if so, please benchmark it first: As I mentioned, are you sure you need to initialise the cipher for each block? If it's slower in software then we need to keep the old version and only use the JCA version on startup ... I suspect that 256-bit block size isn't hardware accelerated, and certainly it isn't the standard. So the original plan was to switch to standard AES (256-bit key, 128-bit block size), which would have required using CFB (which the JCA probably implements). This isn't a criticism anyway. If we can switch to the JVM's AES implementation without even any back compatibility issues, and without a performance loss, that would be really nice. > > Also wanted some opinion on the idea "Switch from the current code to > JCA". Since I have been working and reading on this, I thought I ll > send in a proposal for this task too. Any pointers or suggestions will > be helpful. I will make a rough draft and mail that too, though there > is hardly any time left for discussion. Well, the above suggests it'd be a fairly small project, although we'd want to switch some algorithms, such as the above, at the same time. > > Thank you -- 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: <https://emu.freenetproject.org/pipermail/devl/attachments/20120405/e06a42d1/attachment.pgp>
Re: [freenet-dev] bigint-gnu-gmp and bigint7
On 05/04/12 19:32, Ximin Luo wrote: > I haven't looked at them for a while, but if I remember right: > > bigint7: benchmark the performance of java 7 biginteger > bigint-gnu-gmp: benchmark the performance of gmp-java's biginteger > > gmp-java is my take on NativeBigInteger: > > https://github.com/infinity0/mozilla-gnome-keyring fuck sakes, clipboard fail. right one: https://github.com/infinity0/gmp-java > > it performs better than it, and is simpler to build than all of that native > crap, and allows us to get rid of the mess that is CPUInformation as well. > > I suggest we migrate to it, but only after we split off freenet-ext.jar > > (There's a lot of things that depend on this split, we need to get this done > with high priority.) > > X > > On 05/04/12 15:29, Matthew Toseland wrote: >> What is the purpose of the bigint-gnu-gmp branch? And bigint7? >> >> >> >> ___ >> 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 -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] bigint-gnu-gmp and bigint7
I haven't looked at them for a while, but if I remember right: bigint7: benchmark the performance of java 7 biginteger bigint-gnu-gmp: benchmark the performance of gmp-java's biginteger gmp-java is my take on NativeBigInteger: https://github.com/infinity0/mozilla-gnome-keyring it performs better than it, and is simpler to build than all of that native crap, and allows us to get rid of the mess that is CPUInformation as well. I suggest we migrate to it, but only after we split off freenet-ext.jar (There's a lot of things that depend on this split, we need to get this done with high priority.) X On 05/04/12 15:29, Matthew Toseland wrote: > What is the purpose of the bigint-gnu-gmp branch? And bigint7? > > > > ___ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] JCA patch
Hi Sorry but I didn't understand what you meant by (on github) ->This is actually using 256/256 Rijndael, the JVM appears to allow it. Is the JCA encryption same as Rijndael or my code is still using Rijndael instead of JCA? I tested this and JCA was being called. If its same as Rijndael I get what you mean, that a new negtype is not needed. Also I should actually test it with (256, 128). ->probably require switching to the standard CFB mode I am already using JCA in AES CFB mode as the default. Though I am not sure what happens when key = block = 256. I ll check that. I will also try without Rijndael (probably modify Rijndael.java file itself to use JCA, as a temporary hack?). If it works I will benchmark it and then let you know. The initialisation is needed each time for choosing the mode - encrypt or decrypt. But I can initialise two ciphers in JCACipher, one for encryption and another for decryption. So that would make it faster, probably. I ll test each of them for performance and post them here. Thank you On Thu, Apr 5, 2012 at 5:28 PM, Matthew Toseland wrote: > On Tuesday 03 Apr 2012 22:01:40 Chetan Hosmani wrote: >> Hello, >> >> nextgens as you wanted some changes I have implemented them. I have >> sent a pull request to freenet:next. >> Here is the patch. > > Cool. > > It's here: > https://github.com/freenet/fred-staging/pull/88 > > There was some confusion about this. From your code it appears that we can > just specify a 256 bit block size and the standard code will work. In which > case, the new encryption is exactly the same as the old: 256-bit key, 256-bit > block size, with PCFB mode on top. So you don't need the new negType. Please > test this. If it works, you can use it everywhere in the code, and get rid of > Rijndael, which would be pretty cool. But if so, please benchmark it first: > As I mentioned, are you sure you need to initialise the cipher for each > block? If it's slower in software then we need to keep the old version and > only use the JCA version on startup ... > > I suspect that 256-bit block size isn't hardware accelerated, and certainly > it isn't the standard. So the original plan was to switch to standard AES > (256-bit key, 128-bit block size), which would have required using CFB (which > the JCA probably implements). > > This isn't a criticism anyway. If we can switch to the JVM's AES > implementation without even any back compatibility issues, and without a > performance loss, that would be really nice. >> >> Also wanted some opinion on the idea "Switch from the current code to >> JCA". Since I have been working and reading on this, I thought I ll >> send in a proposal for this task too. Any pointers or suggestions will >> be helpful. I will make a rough draft and mail that too, though there >> is hardly any time left for discussion. > > Well, the above suggests it'd be a fairly small project, although we'd want > to switch some algorithms, such as the above, at the same time. >> >> Thank you ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] GsoC - FCP Library
El 05/04/12 08:09, Matthew Toseland escribió:
On Thursday 05 Apr 2012 06:40:58 Israel Leiva wrote:
Alright. Here is a simple demo of what I thought for the FCP2 Perl library.
http://csrg.cl/~ileiva/gsoc/
The directory includes (all files were renamed to .txt so you could read
it online):
client.pl.txt-- Simple use of FCP2 Perl library
Freenet/FCP2.pm.txt -- FCP2 Perl Module (demo)
Freenet/FCP2/Message.pm.txt -- Message interface for FCP2 Module (demo)
Freenet/FCP2.pod.txt -- Documentation for FCP2.pm
Freenet/FCP2-Message.pod.txt -- Documentation for FCP2/Message.pm Module
(demo)
output.txt -- Results for the use of client.pl
readme.txt -- You should read this if you want to try this Library at
your own
Freenet-FCP2-demo.tar.gz -- All the files
Note: Documentation files should be readed with _perldoc_ . Look at the
readme.txt for more details.
I'm open to suggestions/ideas/comments.
Anyone interested in mentoring this? I really don't think I'm the right person
to mentor a perl project.
IMHO there is no need to have an advanced knowledge in Perl to supervise
such a project. I tried to make the demo as OO as I could so even
someone familiar with PHP or similar could understand it. As I see it,
one option is that the progress on a new FCP Library could be
reflected/measured by a well documentation process (of the Library).
I believe times where Perl was an encryption method are far behind. Just
to give an example, I don't think this is a 'write-only' script (as
someone said on IRC):
$ans = $client->hello();
print $ans->get('Version');
print "\n";
Anyway, I hope someone could have the time to mentor this, I'm very
excited about it.
Best Regards.
--
Israel Leiva
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] bigint-gnu-gmp and bigint7
What is the purpose of the bigint-gnu-gmp branch? And bigint7? 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] Space stripping
Re 2d011ed5bd2f59b0a1a90383566b2f62378245b8 (origin/accept-linewrapped-keys): IMHO we should only try stripping spaces after we have failed to parse without stripping them. So it should be an option on decode(), and FreenetURI should try with and without. 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
Re: [freenet-dev] Can we just put the new wrapper jar on the classpath?
On Tuesday 03 Apr 2012 20:57:08 Ximin Luo wrote: > On 03/04/12 19:57, Matthew Toseland wrote: > > Nextgens is convinced that many of the problems users have installing on > > Windows are due to firewalls blocking the localhost connection between the > > wrapper binary and the JVM running Freenet. The usual solution proposed is > > to split up freenet-ext.jar, which infinity0 has been working on. Can we do > > a quick fix though? Just introduce the new wrapper jar on the classpath in > > new installs, so that it overrides the wrapper classes in freenet-ext.jar? > > The main difficulty appears to be update.cmd - on Windows, it will clobber > > wrapper.conf in some circumstances, in which case it could revert it to a > > version without the new wrapper.jar and thus break it. > > > > See bug: https://bugs.freenetproject.org/view.php?id=4075 > > How does splitting up freenet-ext.jar help with "not creating a localhost > socket"? > > i.e. can you explain the solution in more detail. Wrapper 3.4 allows you to use a named pipe instead, from a config option in wrapper.conf. This avoids firewall issues and so hopefully results in a more reliable setup on Windows. 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
Re: [freenet-dev] GSoC 2012 Transport Plugin
On Thursday 05 Apr 2012 14:29:12 Chetan Hosmani wrote: > Thank you so much toad. Its very detailed and I ll need to go through > it thoroughly. > > Also I am not sure this is relevant, but I did get a mail from a > "stranger" who happened to be going through the archives and decided > to send me an opinion. I thought it's best if we discussed here. I > requested the person to participate here, and will hopefully do so. > > On Wed, Apr 4, 2012 at 1:16 PM, cagsm wrote: > Hello GSOC participant, > > I am not on the Freenet mailing list, but I read the archvies and I > have seen an interesting discussion on Freenet (insinde Freenet, > within the FMS communications tool, in the Freenet forum there). Some > fellow FMS/Freenet user proposed to look at the open source project > "udt" (Sourceforge), that is essentially an intelligent and very > robust and proven way to do udp communications. > > If you are already re-implementing the old raw udp way of Freenet > transport layers and modularizing it, which is needed due to > compatibility reasons as another fellow FMS/Freenet participant (bombe > I think) pointed out, then it would be probably better to migrate away > from the raw udp way to the udt way in the long run, before attempting > the next real transport plugin (tcp). > > Please consider into looking at the udt project and making use of it. > Would be very glad if you could include it in Freenet. > http://udt.sourceforge.net/ I don't think the transport layer is a big performance issue for Freenet, which is the real reason why people want utp. Maybe it's a minor one. In any case, we can't use utp directly. Whatever we use, the basic UDP-based FNP must be hard to identify. Using utp, or any other off the shelf transport, without wrapping it in an outer layer of obfuscation-encryption, would violate this goal, as all such protocols are easily identified. An obscure one like utp that nobody else uses would be particularly easily identified. A big part of the purpose of transport plugins is so Freenet can send traffic that looks like other, common, things, such as VoIP traffic - this is not possible if we use utp. > > On Thu, Apr 5, 2012 at 6:21 PM, Matthew Toseland > wrote: > > On Wednesday 04 Apr 2012 07:15:26 Chetan Hosmani wrote: > >> Hello, > >> > >> With only three days left for the deadline of submission of proposals > >> I was hoping I could get some suggestions on my proposal. > >> This is my only proposal. I am also working on another proposal to > >> Freenet itself (implementing JCA). > >> Any suggestions will be really helpful. > >> > >> The proposal can viewed publicly here- > >> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/chetanhosmani/1 > >> > >> Apart from adding references and links, this is the final version. > >> Please leave comments. > > > > The introduction is good. > > > > IMHO it's not grouped *that* tightly: exactly what does NodeCrypto do that > > is low level? The key classes afaics are NewPacketFormat, UdpSocketHandler, > > FNPPacketMangler. IMHO UdpSocketHandler and SocketHandler in general > > already effectively separate the actual socket implementation. Of course > > pretty much all of it assumes a packet transport, e.g. PacketSender > > constantly loops over peers to send packets to them. > > > > We have a structure for messages that are ready to send, PeerMessageQueue > > on PeerNode. > > > > However I agree that the messages-in-flight structure is too tightly > > integrated with NewPacketFormat, in NewPacketFormat itself and > > NewPacketFormatKeyContext. I don't know whether this structure will be > > adequate for *all* transports; it's likely to be overkill for TCP-based > > transports, but for some packet based formats with bigger packets and > > longer latencies it might be too limited? A single messages in flight queue > > makes sense though for robustness, in fact given we assume reliable > > delivery (or throw an exception), it's essential. But I'm not sure how you > > would manage resends for multiple transports... Wouldn't they have separate > > timers etc? Clearly we would want to send a message over another transport > > if one dies, or persistently can't send it ... > > > > NewPacketFormat contains the queue of messages in flight. > > NewPacketFormatKeyContext contains the data on *packets* in flight. TCP > > presumably won't have packets, but will need to group messages and HMAC > > them, and the two streams aren't necessarily perfectly synchronised so we'd > > probably want some sort of sequence number acknowledgements ... > > > > The OldPacketFormat/PacketTracker code can probably be got rid of now, > > people have had plenty of time to upgrade. > > > > If it's acceptable for TCP, then I'm quite happy for you to factor it out > > into another class. Rewriting it yet again would be a lot of work for no > > obvious advantage, but if you have a clear set of reasons for doing so that > > would be inter
Re: [freenet-dev] GSoC 2012 Transport Plugin
Thank you so much toad. Its very detailed and I ll need to go through it thoroughly. Also I am not sure this is relevant, but I did get a mail from a "stranger" who happened to be going through the archives and decided to send me an opinion. I thought it's best if we discussed here. I requested the person to participate here, and will hopefully do so. On Wed, Apr 4, 2012 at 1:16 PM, cagsm wrote: Hello GSOC participant, I am not on the Freenet mailing list, but I read the archvies and I have seen an interesting discussion on Freenet (insinde Freenet, within the FMS communications tool, in the Freenet forum there). Some fellow FMS/Freenet user proposed to look at the open source project "udt" (Sourceforge), that is essentially an intelligent and very robust and proven way to do udp communications. If you are already re-implementing the old raw udp way of Freenet transport layers and modularizing it, which is needed due to compatibility reasons as another fellow FMS/Freenet participant (bombe I think) pointed out, then it would be probably better to migrate away from the raw udp way to the udt way in the long run, before attempting the next real transport plugin (tcp). Please consider into looking at the udt project and making use of it. Would be very glad if you could include it in Freenet. http://udt.sourceforge.net/ On Thu, Apr 5, 2012 at 6:21 PM, Matthew Toseland wrote: > On Wednesday 04 Apr 2012 07:15:26 Chetan Hosmani wrote: >> Hello, >> >> With only three days left for the deadline of submission of proposals >> I was hoping I could get some suggestions on my proposal. >> This is my only proposal. I am also working on another proposal to >> Freenet itself (implementing JCA). >> Any suggestions will be really helpful. >> >> The proposal can viewed publicly here- >> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/chetanhosmani/1 >> >> Apart from adding references and links, this is the final version. >> Please leave comments. > > The introduction is good. > > IMHO it's not grouped *that* tightly: exactly what does NodeCrypto do that is > low level? The key classes afaics are NewPacketFormat, UdpSocketHandler, > FNPPacketMangler. IMHO UdpSocketHandler and SocketHandler in general already > effectively separate the actual socket implementation. Of course pretty much > all of it assumes a packet transport, e.g. PacketSender constantly loops over > peers to send packets to them. > > We have a structure for messages that are ready to send, PeerMessageQueue on > PeerNode. > > However I agree that the messages-in-flight structure is too tightly > integrated with NewPacketFormat, in NewPacketFormat itself and > NewPacketFormatKeyContext. I don't know whether this structure will be > adequate for *all* transports; it's likely to be overkill for TCP-based > transports, but for some packet based formats with bigger packets and longer > latencies it might be too limited? A single messages in flight queue makes > sense though for robustness, in fact given we assume reliable delivery (or > throw an exception), it's essential. But I'm not sure how you would manage > resends for multiple transports... Wouldn't they have separate timers etc? > Clearly we would want to send a message over another transport if one dies, > or persistently can't send it ... > > NewPacketFormat contains the queue of messages in flight. > NewPacketFormatKeyContext contains the data on *packets* in flight. TCP > presumably won't have packets, but will need to group messages and HMAC them, > and the two streams aren't necessarily perfectly synchronised so we'd > probably want some sort of sequence number acknowledgements ... > > The OldPacketFormat/PacketTracker code can probably be got rid of now, people > have had plenty of time to upgrade. > > If it's acceptable for TCP, then I'm quite happy for you to factor it out > into another class. Rewriting it yet again would be a lot of work for no > obvious advantage, but if you have a clear set of reasons for doing so that > would be interesting. > > Re multiple connections to a single peer, this is all in PeerNode. It can > receive messages from any transport (handle*), it has a queue which is read > e.g. when PacketSender asks it to prepare a packet, but a significant part of > the complexity of the UDP transport results from hacks related to various > failure modes in session setup (I believe we spoof a restart in some cases). > As does code elsewhere, e.g. there is a single throttle used by PacketSender > for a PeerNode. > > To implement UDP as a transport plugin, you will need to implement the > transport plugin API *first*, because it is an unreliable packet transport. > You will need to refactor crypto support for the plugin to be where it needs > to be. But it's the same crypto; the main difference is we can handle > multiple connections to the same peer over different IP addresses more > cleanly. > > Then you will need to implemen
Re: [freenet-dev] GSoC 2012 Transport Plugin
On Wednesday 04 Apr 2012 07:15:26 Chetan Hosmani wrote: > Hello, > > With only three days left for the deadline of submission of proposals > I was hoping I could get some suggestions on my proposal. > This is my only proposal. I am also working on another proposal to > Freenet itself (implementing JCA). > Any suggestions will be really helpful. > > The proposal can viewed publicly here- > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/chetanhosmani/1 > > Apart from adding references and links, this is the final version. > Please leave comments. The introduction is good. IMHO it's not grouped *that* tightly: exactly what does NodeCrypto do that is low level? The key classes afaics are NewPacketFormat, UdpSocketHandler, FNPPacketMangler. IMHO UdpSocketHandler and SocketHandler in general already effectively separate the actual socket implementation. Of course pretty much all of it assumes a packet transport, e.g. PacketSender constantly loops over peers to send packets to them. We have a structure for messages that are ready to send, PeerMessageQueue on PeerNode. However I agree that the messages-in-flight structure is too tightly integrated with NewPacketFormat, in NewPacketFormat itself and NewPacketFormatKeyContext. I don't know whether this structure will be adequate for *all* transports; it's likely to be overkill for TCP-based transports, but for some packet based formats with bigger packets and longer latencies it might be too limited? A single messages in flight queue makes sense though for robustness, in fact given we assume reliable delivery (or throw an exception), it's essential. But I'm not sure how you would manage resends for multiple transports... Wouldn't they have separate timers etc? Clearly we would want to send a message over another transport if one dies, or persistently can't send it ... NewPacketFormat contains the queue of messages in flight. NewPacketFormatKeyContext contains the data on *packets* in flight. TCP presumably won't have packets, but will need to group messages and HMAC them, and the two streams aren't necessarily perfectly synchronised so we'd probably want some sort of sequence number acknowledgements ... The OldPacketFormat/PacketTracker code can probably be got rid of now, people have had plenty of time to upgrade. If it's acceptable for TCP, then I'm quite happy for you to factor it out into another class. Rewriting it yet again would be a lot of work for no obvious advantage, but if you have a clear set of reasons for doing so that would be interesting. Re multiple connections to a single peer, this is all in PeerNode. It can receive messages from any transport (handle*), it has a queue which is read e.g. when PacketSender asks it to prepare a packet, but a significant part of the complexity of the UDP transport results from hacks related to various failure modes in session setup (I believe we spoof a restart in some cases). As does code elsewhere, e.g. there is a single throttle used by PacketSender for a PeerNode. To implement UDP as a transport plugin, you will need to implement the transport plugin API *first*, because it is an unreliable packet transport. You will need to refactor crypto support for the plugin to be where it needs to be. But it's the same crypto; the main difference is we can handle multiple connections to the same peer over different IP addresses more cleanly. Then you will need to implement connection setup for stream-based transports, as well as the basic plugin API, and the driver code (I assume a stream-based transport will present a pair of InputStream/OutputStream?). Connection setup should be fairly similar to the existing code. Whether you want to support sending parts of messages like we do with UDP is unclear; see above. IMHO multiple connections between the same two nodes are an essential part of the GSoC, if only because we will want nodes to expose more than one transport, so that they can connect to the maximum possible range of other nodes. So it will be possible that two connection setups complete simultaneously. "Just close one" is not anywhere near as simple as you might think, from my experience with UDP ... I agree that HTTP etc is optional though. Obviously NodeCrypto should have a set of transport addresses, not just the one port number for UDP. I agree that you will need a different SocketHandler base class for stream-based transports. Ideas on where the boundaries lie: - Clearly the packet format is specific to a particular transport type. It will be different for packets vs streams. - Crypto setup for streams could be the same algorithm, but even if it is, it may not share the same code. The current code is designed for lossy packets, whereas a much simpler control flow is possible for a stream. Authentication is obviously different: A packet has an HMAC, whereas for a stream you can use a self-authenticating cipher or you can grou
Re: [freenet-dev] GsoC - FCP Library
On Thursday 05 Apr 2012 06:40:58 Israel Leiva wrote: > El 03/04/12 11:08, Matthew Toseland escribió: > > The python module is used in some important tools, so in principle > > this is a good thing. I'm not competent to review Perl code, maybe we > > can find somebody who is though. Generally we don't accept prior work > > as proof that a student can code, but if it's freenet-specific then > > maybe ... > > Alright. Here is a simple demo of what I thought for the FCP2 Perl library. > > http://csrg.cl/~ileiva/gsoc/ > > The directory includes (all files were renamed to .txt so you could read > it online): > > client.pl.txt-- Simple use of FCP2 Perl library > Freenet/FCP2.pm.txt -- FCP2 Perl Module (demo) > Freenet/FCP2/Message.pm.txt -- Message interface for FCP2 Module (demo) > Freenet/FCP2.pod.txt -- Documentation for FCP2.pm > Freenet/FCP2-Message.pod.txt -- Documentation for FCP2/Message.pm Module > (demo) > output.txt -- Results for the use of client.pl > readme.txt -- You should read this if you want to try this Library at > your own > Freenet-FCP2-demo.tar.gz -- All the files > > Note: Documentation files should be readed with _perldoc_ . Look at the > readme.txt for more details. > > I'm open to suggestions/ideas/comments. Anyone interested in mentoring this? I really don't think I'm the right person to mentor a perl project. > > Best Regards. 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
Re: [freenet-dev] JCA patch
On Tuesday 03 Apr 2012 22:01:40 Chetan Hosmani wrote: > Hello, > > nextgens as you wanted some changes I have implemented them. I have > sent a pull request to freenet:next. > Here is the patch. Cool. It's here: https://github.com/freenet/fred-staging/pull/88 There was some confusion about this. From your code it appears that we can just specify a 256 bit block size and the standard code will work. In which case, the new encryption is exactly the same as the old: 256-bit key, 256-bit block size, with PCFB mode on top. So you don't need the new negType. Please test this. If it works, you can use it everywhere in the code, and get rid of Rijndael, which would be pretty cool. But if so, please benchmark it first: As I mentioned, are you sure you need to initialise the cipher for each block? If it's slower in software then we need to keep the old version and only use the JCA version on startup ... I suspect that 256-bit block size isn't hardware accelerated, and certainly it isn't the standard. So the original plan was to switch to standard AES (256-bit key, 128-bit block size), which would have required using CFB (which the JCA probably implements). This isn't a criticism anyway. If we can switch to the JVM's AES implementation without even any back compatibility issues, and without a performance loss, that would be really nice. > > Also wanted some opinion on the idea "Switch from the current code to > JCA". Since I have been working and reading on this, I thought I ll > send in a proposal for this task too. Any pointers or suggestions will > be helpful. I will make a rough draft and mail that too, though there > is hardly any time left for discussion. Well, the above suggests it'd be a fairly small project, although we'd want to switch some algorithms, such as the above, at the same time. > > Thank you 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] GsoC - FCP Library
El 03/04/12 11:08, Matthew Toseland escribi?: > The python module is used in some important tools, so in principle > this is a good thing. I'm not competent to review Perl code, maybe we > can find somebody who is though. Generally we don't accept prior work > as proof that a student can code, but if it's freenet-specific then > maybe ... Alright. Here is a simple demo of what I thought for the FCP2 Perl library. http://csrg.cl/~ileiva/gsoc/ The directory includes (all files were renamed to .txt so you could read it online): client.pl.txt-- Simple use of FCP2 Perl library Freenet/FCP2.pm.txt -- FCP2 Perl Module (demo) Freenet/FCP2/Message.pm.txt -- Message interface for FCP2 Module (demo) Freenet/FCP2.pod.txt -- Documentation for FCP2.pm Freenet/FCP2-Message.pod.txt -- Documentation for FCP2/Message.pm Module (demo) output.txt -- Results for the use of client.pl readme.txt -- You should read this if you want to try this Library at your own Freenet-FCP2-demo.tar.gz -- All the files Note: Documentation files should be readed with _perldoc_ . Look at the readme.txt for more details. I'm open to suggestions/ideas/comments. Best Regards. -- Israel Leiva
