From david at sowder.com Tue Jan 1 15:23:49 2008 From: david at sowder.com (David Sowder) Date: Tue, 01 Jan 2008 09:23:49 -0600 Subject: [freenet-dev] [freenet-cvs] r16825 - trunk/freenet/src/freenet/node In-Reply-To: <20071228165029.8866D47AEA3@freenetproject.org> References: <20071228165029.8866D47AEA3@freenetproject.org> Message-ID: <477A5B05.6010903@sowder.com> Do we want to print the null? robert at emu.freenetproject.org wrote: > Author: robert > Date: 2007-12-28 16:50:28 +0000 (Fri, 28 Dec 2007) > New Revision: 16825 > > Modified: > trunk/freenet/src/freenet/node/SSKInsertSender.java > Log: > logging > > > Modified: trunk/freenet/src/freenet/node/SSKInsertSender.java > =================================================================== > --- trunk/freenet/src/freenet/node/SSKInsertSender.java 2007-12-27 21:56:35 UTC (rev 16824) > +++ trunk/freenet/src/freenet/node/SSKInsertSender.java 2007-12-28 16:50:28 UTC (rev 16825) > @@ -309,7 +309,7 @@ > if (msg == null) { > // Timeout :( > // Fairly serious problem > - Logger.error(this, "Timeout (" + next + ") after Accepted in insert"); > + Logger.error(this, "Timeout (" + msg + ") after Accepted in insert; to ("+next+")"); > // Terminal overload > // Try to propagate back to source > next.localRejectedOverload("AfterInsertAcceptedTimeout"); > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > -- David R. Sowder Linux Systems Administrator (Software Systems Specialist II) Office of Information Technology University of Texas at Arlington Work: 817-272-1081 davids at uta.edu http://www.uta.edu/ Personal: david at sowder.com http://david.sowder.com/ From toad at amphibian.dyndns.org Wed Jan 2 12:57:18 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 12:57:18 +0000 Subject: [freenet-dev] [freenet-cvs] r16825 - trunk/freenet/src/freenet/node In-Reply-To: <477A5B05.6010903@sowder.com> References: <20071228165029.8866D47AEA3@freenetproject.org> <477A5B05.6010903@sowder.com> Message-ID: <200801021257.18435.toad@amphibian.dyndns.org> On Tuesday 01 January 2008 15:23, David Sowder wrote: > Do we want to print the null? Probably a good idea. > > robert at emu.freenetproject.org wrote: > > Author: robert > > Date: 2007-12-28 16:50:28 +0000 (Fri, 28 Dec 2007) > > New Revision: 16825 > > > > Modified: > > trunk/freenet/src/freenet/node/SSKInsertSender.java > > Log: > > logging > > > > > > Modified: trunk/freenet/src/freenet/node/SSKInsertSender.java > > =================================================================== > > --- trunk/freenet/src/freenet/node/SSKInsertSender.java 2007-12-27 21:56:35 UTC (rev 16824) > > +++ trunk/freenet/src/freenet/node/SSKInsertSender.java 2007-12-28 16:50:28 UTC (rev 16825) > > @@ -309,7 +309,7 @@ > > if (msg == null) { > > // Timeout :( > > // Fairly serious problem > > - Logger.error(this, "Timeout (" + next + ") after Accepted in insert"); > > + Logger.error(this, "Timeout (" + msg + ") after Accepted in insert; to ("+next+")"); > > // Terminal overload > > // Try to propagate back to source > > next.localRejectedOverload("AfterInsertAcceptedTimeout"); > > > > _______________________________________________ > > cvs mailing list > > cvs at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > > > > -- > David R. Sowder > Linux Systems Administrator (Software Systems Specialist II) > Office of Information Technology > University of Texas at Arlington > Work: 817-272-1081 davids at uta.edu http://www.uta.edu/ > Personal: david at sowder.com http://david.sowder.com/ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/3e810fe1/attachment.pgp From toad at amphibian.dyndns.org Wed Jan 2 12:58:45 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 12:58:45 +0000 Subject: [freenet-dev] [freenet-cvs] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <20071229113933.GD4199@freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229110517.GB4199@freenetproject.org> <20071229113933.GD4199@freenetproject.org> Message-ID: <200801021258.46217.toad@amphibian.dyndns.org> On Saturday 29 December 2007 11:39, Florent Daigni?re wrote: > * Florent Daigni?re [2007-12-29 12:05:17]: > > > * robert at freenetproject.org [2007-12-29 01:46:31]: > > > > > Author: robert > > > Date: 2007-12-29 01:46:31 +0000 (Sat, 29 Dec 2007) > > > New Revision: 16834 > > > > > > Modified: > > > trunk/freenet/src/freenet/node/PeerNode.java > > > Log: > > > maybe help wont-fetch-ark deadlock #2 > > > > > > > > > Modified: trunk/freenet/src/freenet/node/PeerNode.java > > > =================================================================== > > > --- trunk/freenet/src/freenet/node/PeerNode.java 2007-12-29 01:41:06 UTC (rev 16833) > > > +++ trunk/freenet/src/freenet/node/PeerNode.java 2007-12-29 01:46:31 UTC (rev 16834) > > > @@ -2782,7 +2782,7 @@ > > > > > > synchronized void updateShouldDisconnectNow() { > > > //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH THE NODE > > > - if (isConnected()) { > > > + if (isConnected() || verifiedIncompatibleOlderVersion || verifiedIncompatibleNewerVersion) { > > > verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > > > verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > > > } > > > > I suggest you call isRoutable() instead > > > > NextGen$ > > Hmm, on a latter thought, I don't understand why it helps... nor why we > are calling it from PacketSender > > What about getting rid of both the "if" branch and the call in > PacketSender ? Why not just use if(isConnected()) { ... } ? As far as I can see that is correct: if we're not connected, we don't care about verified*. > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/60d9ba92/attachment.pgp From nextgens at freenetproject.org Wed Jan 2 13:38:04 2008 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Wed, 2 Jan 2008 14:38:04 +0100 Subject: [freenet-dev] [freenet-cvs] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <200801021258.46217.toad@amphibian.dyndns.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229110517.GB4199@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801021258.46217.toad@amphibian.dyndns.org> Message-ID: <20080102133803.GA4775@freenetproject.org> * Matthew Toseland [2008-01-02 12:58:45]: > On Saturday 29 December 2007 11:39, Florent Daigni?re wrote: > > * Florent Daigni?re [2007-12-29 12:05:17]: > > > > > * robert at freenetproject.org [2007-12-29 > 01:46:31]: > > > > > > > Author: robert > > > > Date: 2007-12-29 01:46:31 +0000 (Sat, 29 Dec 2007) > > > > New Revision: 16834 > > > > > > > > Modified: > > > > trunk/freenet/src/freenet/node/PeerNode.java > > > > Log: > > > > maybe help wont-fetch-ark deadlock #2 > > > > > > > > > > > > Modified: trunk/freenet/src/freenet/node/PeerNode.java > > > > =================================================================== > > > > --- trunk/freenet/src/freenet/node/PeerNode.java 2007-12-29 01:41:06 UTC > (rev 16833) > > > > +++ trunk/freenet/src/freenet/node/PeerNode.java 2007-12-29 01:46:31 UTC > (rev 16834) > > > > @@ -2782,7 +2782,7 @@ > > > > > > > > synchronized void updateShouldDisconnectNow() { > > > > //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH THE > NODE > > > > - if (isConnected()) { > > > > + if (isConnected() || verifiedIncompatibleOlderVersion || > verifiedIncompatibleNewerVersion) { > > > > verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > > > > verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > > > > } > > > > > > I suggest you call isRoutable() instead > > > > > > NextGen$ > > > > Hmm, on a latter thought, I don't understand why it helps... nor why we > > are calling it from PacketSender > > > > What about getting rid of both the "if" branch and the call in > > PacketSender ? > > Why not just use if(isConnected()) { ... } ? As far as I can see that is > correct: if we're not connected, we don't care about verified*. You're suggesting to revert robert's patch, wich is fine by me... as I said, I don't understand why it helps NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/2e8eff83/attachment.pgp From toad at amphibian.dyndns.org Wed Jan 2 12:56:11 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 12:56:11 +0000 Subject: [freenet-dev] [freenet-cvs] r16775 - in trunk/freenet/src/freenet: clients/http crypt io l10n node node/fcp In-Reply-To: <20071225011902.GA5185@freenetproject.org> References: <20071222001228.E0436479FBC@freenetproject.org> <20071225011902.GA5185@freenetproject.org> Message-ID: <200801021256.11404.toad@amphibian.dyndns.org> Ian: example of why we need DVCS IMHO. I committed a patch from ET on Frost, because I want anonymous contributors, and to encourage a new dev. I did a basic code review (and gave input on architecture, this is the second patch to be committed), now nextgens is quibbling about it... On Tuesday 25 December 2007 01:19, Florent Daigni?re wrote: > * toad at freenetproject.org [2007-12-22 00:12:28]: > > > Author: toad > > Date: 2007-12-22 00:12:28 +0000 (Sat, 22 Dec 2007) > > New Revision: 16775 > > > > Added: > > trunk/freenet/src/freenet/crypt/SSL.java > > trunk/freenet/src/freenet/io/SSLNetworkInterface.java > > Modified: > > trunk/freenet/src/freenet/clients/http/SimpleToadletServer.java > > trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties > > trunk/freenet/src/freenet/node/NodeStarter.java > > trunk/freenet/src/freenet/node/TextModeClientInterfaceServer.java > > trunk/freenet/src/freenet/node/fcp/FCPServer.java > > Log: > > Patch from ET at mj+bSV4hxRMtCj9fcwy4Ww9_3mc on Frost: Add SSL support for FCP, HTTP, TMCI. > > Request testing! > > > > Why has it been commited and released ? > 1) it depends on sun.security.x509.X500Name Which is bad because...? > 2) errors sent back by the config. framework aren't > internationalized AFAIK this is a problem in many places in Fred. > 3) they are obvious typos and french comments! Okay, French comments are bad. I did read it before I committed it, it seemed okay, but maybe I was asleep at that point. > > Don't get me wrong: contributions are welcome... but they should meet a > given quality standard to get merged and deployed. How do you propose we discuss such contributions? Did you see it on Frost? Our current protocol is to throw everything into trunk, 99% of the time. Maybe it should have gone into a branch, but IMHO the ideal is a DVCS so I can just post the (freenet-based) url on devl. I don't suppose you'd be interested in getting that working? > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/b3dca549/attachment.pgp From toad at amphibian.dyndns.org Wed Jan 2 12:56:11 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 12:56:11 +0000 Subject: [freenet-dev] [freenet-cvs] r16775 - in trunk/freenet/src/freenet: clients/http crypt io l10n node node/fcp In-Reply-To: <20071225011902.GA5185@freenetproject.org> References: <20071222001228.E0436479FBC@freenetproject.org> <20071225011902.GA5185@freenetproject.org> Message-ID: <200801021256.11404.toad@amphibian.dyndns.org> Ian: example of why we need DVCS IMHO. I committed a patch from ET on Frost, because I want anonymous contributors, and to encourage a new dev. I did a basic code review (and gave input on architecture, this is the second patch to be committed), now nextgens is quibbling about it... On Tuesday 25 December 2007 01:19, Florent Daigni?re wrote: > * toad at freenetproject.org [2007-12-22 00:12:28]: > > > Author: toad > > Date: 2007-12-22 00:12:28 +0000 (Sat, 22 Dec 2007) > > New Revision: 16775 > > > > Added: > > trunk/freenet/src/freenet/crypt/SSL.java > > trunk/freenet/src/freenet/io/SSLNetworkInterface.java > > Modified: > > trunk/freenet/src/freenet/clients/http/SimpleToadletServer.java > > trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties > > trunk/freenet/src/freenet/node/NodeStarter.java > > trunk/freenet/src/freenet/node/TextModeClientInterfaceServer.java > > trunk/freenet/src/freenet/node/fcp/FCPServer.java > > Log: > > Patch from ET at mj+bSV4hxRMtCj9fcwy4Ww9_3mc on Frost: Add SSL support for FCP, HTTP, TMCI. > > Request testing! > > > > Why has it been commited and released ? > 1) it depends on sun.security.x509.X500Name Which is bad because...? > 2) errors sent back by the config. framework aren't > internationalized AFAIK this is a problem in many places in Fred. > 3) they are obvious typos and french comments! Okay, French comments are bad. I did read it before I committed it, it seemed okay, but maybe I was asleep at that point. > > Don't get me wrong: contributions are welcome... but they should meet a > given quality standard to get merged and deployed. How do you propose we discuss such contributions? Did you see it on Frost? Our current protocol is to throw everything into trunk, 99% of the time. Maybe it should have gone into a branch, but IMHO the ideal is a DVCS so I can just post the (freenet-based) url on devl. I don't suppose you'd be interested in getting that working? > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/b3dca549/attachment-0001.pgp From nextgens at freenetproject.org Wed Jan 2 15:56:08 2008 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Wed, 2 Jan 2008 16:56:08 +0100 Subject: [freenet-dev] [freenet-cvs] r16775 - in trunk/freenet/src/freenet: clients/http crypt io l10n node node/fcp In-Reply-To: <200801021256.11404.toad@amphibian.dyndns.org> References: <20071222001228.E0436479FBC@freenetproject.org> <20071225011902.GA5185@freenetproject.org> <200801021256.11404.toad@amphibian.dyndns.org> Message-ID: <20080102155608.GC4775@freenetproject.org> * Matthew Toseland [2008-01-02 12:56:11]: > On Tuesday 25 December 2007 01:19, Florent Daigni?re wrote: > > * toad at freenetproject.org [2007-12-22 00:12:28]: > > > > > Author: toad > > > Date: 2007-12-22 00:12:28 +0000 (Sat, 22 Dec 2007) > > > New Revision: 16775 > > > > > > Added: > > > trunk/freenet/src/freenet/crypt/SSL.java > > > trunk/freenet/src/freenet/io/SSLNetworkInterface.java > > > Modified: > > > trunk/freenet/src/freenet/clients/http/SimpleToadletServer.java > > > trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties > > > trunk/freenet/src/freenet/node/NodeStarter.java > > > trunk/freenet/src/freenet/node/TextModeClientInterfaceServer.java > > > trunk/freenet/src/freenet/node/fcp/FCPServer.java > > > Log: > > > Patch from ET at mj+bSV4hxRMtCj9fcwy4Ww9_3mc on Frost: Add SSL support for > FCP, HTTP, TMCI. > > > Request testing! > > > > > > > Why has it been commited and released ? > > 1) it depends on sun.security.x509.X500Name > > Which is bad because...? It breaks freejvm support (freenet is reported to be working on recent gij) > > > 2) errors sent back by the config. framework aren't > > internationalized > > AFAIK this is a problem in many places in Fred. True but introducing more is definitely not going to help ;) > > > 3) they are obvious typos and french comments! > > Okay, French comments are bad. I did read it before I committed it, it seemed > okay, but maybe I was asleep at that point. > > > > Don't get me wrong: contributions are welcome... but they should meet a > > given quality standard to get merged and deployed. > > How do you propose we discuss such contributions? Well, it's clear that we aren't ready to deal with "big" anonymous contributions... but so far it hasn't been a worry because we don't have many anon. contributors... and most of the time they publish trivial patches. >Did you see it on Frost? Yes, and there too I was the first one to criticize it > Our current protocol is to throw everything into trunk, 99% of the time. Maybe it > should have gone into a branch, I think it would have been better for it to remain in a branch, yes. I have no problem with such patches being in our trunk... but you shouldn't release right after they have been introduced. > but IMHO the ideal is a DVCS so I can just > post the (freenet-based) url on devl. I don't suppose you'd be interested in > getting that working? I have no time to do it atm... but will have a look after I've passed my exams. I'm reluctant to use a DSCM in our case for a few reasons: 1) they are more difficult to use: that will be one additional fence each of our contributors will have to pass before he can start to contribute 2) they are "young": more likely to be prone to bugs and stuffs like that (keep in mind that we did experience data corruption with svn... which is believed to be robust!) 3) last time I checked they weren't any "good" GUIs: you are the one who told me "as long as there is an eclipse integration I don't mind what we are using" back when I made you switch from CVS to SVN ;) If you're still convinced that it's the way to go, I'll have a closer look to what's doable... We did talk about it at the gSoC mentor summit and because of my point (1) we ended up concluding "maybe latter". NextGen$ PS: a point I forgot to state in my previous email : from an architectural point of view, I don't think that we should have "one" fproxy but more... One with and one without ssl support, possibly running on different port numbers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/fe3274d2/attachment.pgp From robert at emu.freenetproject.org Wed Jan 2 17:22:17 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Wed, 2 Jan 2008 11:22:17 -0600 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <20071229113933.GD4199@freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229110517.GB4199@freenetproject.org> <20071229113933.GD4199@freenetproject.org> Message-ID: On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: >>> synchronized void updateShouldDisconnectNow() { >>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>> THE NODE >>> - if (isConnected()) { >>> + if (isConnected() || verifiedIncompatibleOlderVersion || >>> verifiedIncompatibleNewerVersion) { >>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>> } >> >> I suggest you call isRoutable() instead >> >> NextGen$ > > Hmm, on a latter thought, I don't understand why it helps... nor why > we > are calling it from PacketSender > > What about getting rid of both the "if" branch and the call in > PacketSender ? In PacketSender this function is called ~precisely~ at the version transition time so that all peers will be re-evaluated concerning compatible versioning; this seems like an odd place to stick this code, but also updateShouldDisconnectNow() does not explicitly disconnect the peer node, it only updates the 'incompatible' flags. Concerning the if branch I added, the intended behaviour change is that this function should only (1) allow the disconnection of a connected peer by setting the incompatible flag, or (2) remove an incompatible flag (e.g. on the fetch of an ark). Now, if the nodes can handshake, this code has probably has little effect, as it simply further restricts one of only two places that the incompatible flags are set (the other being on a handshake). What it will do is if the nodes can't talk to each other (like in my re-keyed node case), is not show 'TOO_OLD'/'TOO_NEW', but instead 'DISCONNECTED'. And I suppose in the same error case... if the node is restarted, it would never be able to verify that the peer is too old/ new and fetch the ark (keeping the version number up-to-date). Really this change just brings the functionality of the incompatibility flags closer to the comments thereon: that they are only set if we have verified incompatibility through a handshake. In practice, it appears that they could still be set upon receiving a new reference (ark?) as well. -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emu.freenetproject.org/pipermail/devl/attachments/20080102/0836e813/attachment.htm From robert at emu.freenetproject.org Wed Jan 2 17:30:18 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Wed, 2 Jan 2008 11:30:18 -0600 Subject: [freenet-dev] [freenet-cvs] r16825 - trunk/freenet/src/freenet/node In-Reply-To: <200801021257.18435.toad@amphibian.dyndns.org> References: <20071228165029.8866D47AEA3@freenetproject.org> <477A5B05.6010903@sowder.com> <200801021257.18435.toad@amphibian.dyndns.org> Message-ID: On Jan 2, 2008, at 6:57 AM, Matthew Toseland wrote: > On Tuesday 01 January 2008 15:23, David Sowder wrote: >> Do we want to print the null? > > Probably a good idea. It does seem kind of weird perhaps (as msg will always be null), but it makes the logging match that in CHKInsertSender, and when reading it in the log files it makes more sense (than received a... ? peernode?!). The CHK log statement can also have a rejected/overload- timeout or something. -- Robert Hailey >> if (msg == null) { >> // Timeout :( >> // Fairly serious problem >> - Logger.error(this, "Timeout (" + next + ") after Accepted in >> insert"); >> + Logger.error(this, "Timeout (" + msg + ") after Accepted in >> insert; to ("+next+")"); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emu.freenetproject.org/pipermail/devl/attachments/20080102/2a299ce7/attachment.htm From robert at emu.freenetproject.org Wed Jan 2 18:15:16 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Wed, 2 Jan 2008 12:15:16 -0600 Subject: [freenet-dev] [freenet-cvs] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <20080102133803.GA4775@freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229110517.GB4199@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801021258.46217.toad@amphibian.dyndns.org> <20080102133803.GA4775@freenetproject.org> Message-ID: <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> On Jan 2, 2008, at 7:38 AM, Florent Daigni?re wrote: >>>>> synchronized void updateShouldDisconnectNow() { >>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>>>> THE NODE >>>>> - if (isConnected()) { >>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || >>>>> verifiedIncompatibleNewerVersion) { >>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>>>> } >>>> >>>> I suggest you call isRoutable() instead >>>> >>>> NextGen$ >>> >>> Hmm, on a latter thought, I don't understand why it helps... nor >>> why we >>> are calling it from PacketSender >>> >>> What about getting rid of both the "if" branch and the call in >>> PacketSender ? >> >> Why not just use if(isConnected()) { ... } ? As far as I can see >> that is >> correct: if we're not connected, we don't care about verified*. > > You're suggesting to revert robert's patch, wich is fine by me... as I > said, I don't understand why it helps > > NextGen$ This function is called at various times (connected or not). If the only condition baring updating the 'verified' flags is: "isConnected()"... then the added condition could SET the verified- incompatible flags but could not UNSET them unless connected. The purpose for adding the extra OR's to the conditional is to allow this function to clear the verified-incompatible flags even if not connected (e.g. new ark fetched, node has a new version, clear the verified-flag). I have had what appears to be this 'deadlock' twice, the first with a laptop (whose IP and node-version changed at the same time), and it is this: (1) last-seen node version is incompatible (but before r16834, would set 'verified') (2) attempt handshakes, but don't fetch ark (3) IP has changed, so can't handshake (4) wont get new IP (ark), because older version A better solution to this might simply be to fetch arks even on version incompatibility, but (for caution) behavior #2 seemed intentional (dont fetch ark on incompatible version), whereas #1 did not, and brought it closer to the comments (i.e. don't set 'verified' unless handshake). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emu.freenetproject.org/pipermail/devl/attachments/20080102/0806e301/attachment.htm From freenet-devl at david.sowder.com Wed Jan 2 18:30:59 2008 From: freenet-devl at david.sowder.com (David Sowder) Date: Wed, 02 Jan 2008 12:30:59 -0600 Subject: [freenet-dev] [freenet-cvs] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229110517.GB4199@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801021258.46217.toad@amphibian.dyndns.org> <20080102133803.GA4775@freenetproject.org> <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> Message-ID: <477BD863.50803@david.sowder.com> I'm not sure of the thinking of others regarding changes to the verifiedIncompatible variables since, but my thinking in my initial implementation was that they would only be set after a handshake, thus we already had a connected to them and ARKs weren't needed. That won't change until the peer re-handshakes after restarting with a different version of the node's software. Robert Hailey wrote: > > On Jan 2, 2008, at 7:38 AM, Florent Daigni?re wrote: > >>>>>> synchronized void updateShouldDisconnectNow() { >>>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>>>>> THE NODE >>>>>> - if (isConnected()) { >>>>>> + if (isConnected() || verifiedIncompatibleOlderVersion >>>>>> || verifiedIncompatibleNewerVersion) { >>>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>>>>> } >>>>> >>>>> I suggest you call isRoutable() instead >>>>> >>>>> NextGen$ >>>> >>>> Hmm, on a latter thought, I don't understand why it helps... nor why we >>>> are calling it from PacketSender >>>> >>>> What about getting rid of both the "if" branch and the call in >>>> PacketSender ? >>> >>> Why not just use if(isConnected()) { ... } ? As far as I can see >>> that is >>> correct: if we're not connected, we don't care about verified*. >> >> You're suggesting to revert robert's patch, wich is fine by me... as I >> said, I don't understand why it helps >> >> NextGen$ > > This function is called at various times (connected or not). If the > only condition baring updating the 'verified' flags is: > "isConnected()"... then the added condition could SET the > verified-incompatible flags but could not UNSET them unless connected. > The purpose for adding the extra OR's to the conditional is to allow > this function to clear the verified-incompatible flags even if not > connected (e.g. new ark fetched, node has a new version, clear the > verified-flag). > > I have had what appears to be this 'deadlock' twice, the first with a > laptop (whose IP and node-version changed at the same time), and it is > this: > (1) last-seen node version is incompatible (but before r16834, would > set 'verified') > (2) attempt handshakes, but don't fetch ark > (3) IP has changed, so can't handshake > (4) wont get new IP (ark), because older version > > A better solution to this might simply be to fetch arks even on > version incompatibility, but (for caution) behavior #2 seemed > intentional (dont fetch ark on incompatible version), whereas #1 did > not, and brought it closer to the comments (i.e. don't set 'verified' > unless handshake). > > -- > Robert Hailey > > ------------------------------------------------------------------------ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl From toad at amphibian.dyndns.org Wed Jan 2 21:37:46 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 21:37:46 +0000 Subject: [freenet-dev] =?utf-8?q?=5Bfreenet-cvs=5D_r16834_-=09trunk/freene?= =?utf-8?q?t/src/freenet/node?= In-Reply-To: <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20080102133803.GA4775@freenetproject.org> <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> Message-ID: <200801022137.46575.toad@amphibian.dyndns.org> On Wednesday 02 January 2008 18:15, Robert Hailey wrote: > > On Jan 2, 2008, at 7:38 AM, Florent Daigni?re wrote: > > >>>>> synchronized void updateShouldDisconnectNow() { > >>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH > >>>>> THE NODE > >>>>> - if (isConnected()) { > >>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || > >>>>> verifiedIncompatibleNewerVersion) { > >>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > >>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > >>>>> } > >>>> > >>>> I suggest you call isRoutable() instead > >>>> > >>>> NextGen$ > >>> > >>> Hmm, on a latter thought, I don't understand why it helps... nor > >>> why we > >>> are calling it from PacketSender > >>> > >>> What about getting rid of both the "if" branch and the call in > >>> PacketSender ? > >> > >> Why not just use if(isConnected()) { ... } ? As far as I can see > >> that is > >> correct: if we're not connected, we don't care about verified*. > > > > You're suggesting to revert robert's patch, wich is fine by me... as I > > said, I don't understand why it helps > > > > NextGen$ > > This function is called at various times (connected or not). If the > only condition baring updating the 'verified' flags is: > "isConnected()"... then the added condition could SET the verified- > incompatible flags but could not UNSET them unless connected. The > purpose for adding the extra OR's to the conditional is to allow this > function to clear the verified-incompatible flags even if not > connected (e.g. new ark fetched, node has a new version, clear the > verified-flag). Okay. Why is this a problem? > > I have had what appears to be this 'deadlock' twice, the first with a > laptop (whose IP and node-version changed at the same time), and it is > this: > (1) last-seen node version is incompatible (but before r16834, would > set 'verified') > (2) attempt handshakes, but don't fetch ark Why does it not fetch the ARK? It should fetch the ARK even if it is incompatible. > (3) IP has changed, so can't handshake > (4) wont get new IP (ark), because older version This is the bug afaics. > > A better solution to this might simply be to fetch arks even on > version incompatibility, but (for caution) behavior #2 seemed > intentional (dont fetch ark on incompatible version), whereas #1 did > not, and brought it closer to the comments (i.e. don't set 'verified' > unless handshake). I really don't see any reason not to fetch the ARK just because it was incompatible last time. That's a bug, it's a connectivity problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/1a8982fc/attachment.pgp From toad at amphibian.dyndns.org Wed Jan 2 21:40:34 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 21:40:34 +0000 Subject: [freenet-dev] =?iso-8859-1?q?=5Bfreenet-cvs=5D_r16834=09-=09trunk?= =?iso-8859-1?q?/freenet/src/freenet/node?= In-Reply-To: <477BD863.50803@david.sowder.com> References: <20071229014631.C5D7847A6AE@freenetproject.org> <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> <477BD863.50803@david.sowder.com> Message-ID: <200801022140.35033.toad@amphibian.dyndns.org> On Wednesday 02 January 2008 18:30, David Sowder wrote: > I'm not sure of the thinking of others regarding changes to the > verifiedIncompatible variables since, but my thinking in my initial > implementation was that they would only be set after a handshake, thus > we already had a connected to them and ARKs weren't needed. That won't > change until the peer re-handshakes after restarting with a different > version of the node's software. I don't follow - clearly if isConnected(), we don't need the ARK. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/e11f0e01/attachment.pgp From toad at amphibian.dyndns.org Wed Jan 2 21:44:58 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 21:44:58 +0000 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> Message-ID: <200801022144.58447.toad@amphibian.dyndns.org> On Wednesday 02 January 2008 17:22, Robert Hailey wrote: > > On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: > > >>> synchronized void updateShouldDisconnectNow() { > >>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH > >>> THE NODE > >>> - if (isConnected()) { > >>> + if (isConnected() || verifiedIncompatibleOlderVersion || > >>> verifiedIncompatibleNewerVersion) { > >>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > >>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > >>> } > >> > >> I suggest you call isRoutable() instead > >> > >> NextGen$ > > > > Hmm, on a latter thought, I don't understand why it helps... nor why > > we > > are calling it from PacketSender > > > > What about getting rid of both the "if" branch and the call in > > PacketSender ? > > In PacketSender this function is called ~precisely~ at the version > transition time so that all peers will be re-evaluated concerning > compatible versioning; this seems like an odd place to stick this > code, but also updateShouldDisconnectNow() does not explicitly > disconnect the peer node, it only updates the 'incompatible' flags. We don't want to disconnect. We want to stay connected and to not route requests to the node or accept them from it. We will still accept e.g. Update Over Mandatory traffic. > > Concerning the if branch I added, the intended behaviour change is > that this function should only (1) allow the disconnection of a > connected peer by setting the incompatible flag, No, we don't want to disconnect. We just want to make it non-routable, by updating verified*. > or (2) remove an > incompatible flag (e.g. on the fetch of an ark). > > Now, if the nodes can handshake, this code has probably has little > effect, as it simply further restricts one of only two places that the > incompatible flags are set (the other being on a handshake). What it > will do is if the nodes can't talk to each other (like in my re-keyed > node case), is not show 'TOO_OLD'/'TOO_NEW', but instead > 'DISCONNECTED'. So you are setting verified* to false, because it's not verified? > And I suppose in the same error case... if the node is > restarted, it would never be able to verify that the peer is too old/ > new and fetch the ark (keeping the version number up-to-date). Again, we should always fetch the ARK. > > Really this change just brings the functionality of the > incompatibility flags closer to the comments thereon: that they are > only set if we have verified incompatibility through a handshake. In > practice, it appears that they could still be set upon receiving a new > reference (ark?) as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/e532040c/attachment.pgp From toad at amphibian.dyndns.org Wed Jan 2 23:52:45 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Wed, 2 Jan 2008 23:52:45 +0000 Subject: [freenet-dev] One tunnel per request: justification In-Reply-To: <47779AEF.6080305@cs.ucl.ac.uk> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210025.29457.toad@amphibian.dyndns.org> <47779AEF.6080305@cs.ucl.ac.uk> Message-ID: <200801022352.54143.toad@amphibian.dyndns.org> On Sunday 30 December 2007 13:19, Michael Rogers wrote: > > The idea was to pick two random nodes from within the cell, and route through > > them - choosing a new tunnel for every request. > > Why choose a new tunnel for every request? If an attacker inside the > cell can somehow link messages leaving the cell with messages passing > through his node, he can gather one predecessor attack sample per > intercepted message. True, but: - It is fast. - It is simple. - It should be possible with such a simple request/response to make it extremely difficult for two nodes to realise they are on the same path, except in the case where they are actually adjacent. If: - The two nodes on the path controlled by the attacker are not adjacent, - We have a separate return path included in the routing information, - Each hop waits to receive the full reply before forwarding it, Then it will be very difficult for an attacker to identify that the two nodes are connected afaics: with bidirectional tunnels, his only leverage is the reply time, but with unidirectional tunnels he loses even that. If the two nodes *are* adjacent, we can severely limit the information available: The last node is the second chosen node (assuming we choose two nodes including the exit node). The second-last node is either a node between the first chosen node and the second chosen node, or is in fact the first chosen node, in which case its predecessor is a back-bearing towards the originator. However, we can prevent this by ensuring there is always at least one hop between the first chosen node and the second chosen node. Since this does not give any information on the originator, it should be a safe addition. The separate return path obviously will be unreliable - any node along it could refuse it. This is the same for the outward path: any node could refuse the path, or sabotage it, and it will be impossible to establish which node is at fault since any node can always blame a later node. However, it *is* known that it is one of the nodes along that path that is the problem, and this may be enough. With enough redundancy it might even be possible to make passive requests work through this, although the main concern here is the real time phase of a request. Perhaps I am missing something critical about onion routing here, but what? > > > The one big weakness is that cells would have to be relatively small > > to keep global data available. The complication (IMHO solvable) is bogus > > topology attacks. > > And bogus public key attacks (the nodes beyond my neighbour might really > exist, but my neighbour might MITM their public keys in order to link > traffic passing through his node with traffic exiting the cell). When > you say solvable, what do you have in mind? Each node publishes its links, including its pubkeys, their pubkey hashes, and a signature. This is relayed to some distance. We compute a credibility value for each node on the graph by starting with a value of 1.0 on each node we are a direct peer of, and dividing it by the number of peers on each node going outwards, adding up the values from different branches. We can then ignore nodes which have a low credibility value. Now, we may not be able to do exactly this, if we have to have semi-permanent cell structures, but it should be possible to find an algorithm to serve this purpose (eigenvector centrality? TrustRank etc?). > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080102/7950bb26/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 00:00:05 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 00:00:05 +0000 Subject: [freenet-dev] Why getting rid of HTL is bad was Re: Vulnerability in inserting the manifest before finishing In-Reply-To: <47779AEF.6080305@cs.ucl.ac.uk> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210025.29457.toad@amphibian.dyndns.org> <47779AEF.6080305@cs.ucl.ac.uk> Message-ID: <200801030000.13355.toad@amphibian.dyndns.org> On Sunday 30 December 2007 13:19, Michael Rogers wrote: > Matthew Toseland wrote: > > - Not compatible afaics with ULPRs / failure tables. ULPRs stop requests if > > we've routed them already (for some period), with the same HTL or less. > > Good point, and I guess the same would be true of request coalescing. > Maybe we could get a similar effect by using the weighted coin to decide > whether to coalesce or forward the new request. > > > - Load management issues maybe. > > Do we currently use the hop counter for any load management decisions? No, but it would make the request time variance much higher, especially for inserts and unsuccessful requests (which can potentially visit the entire network). > > > - It's a good "invisible" DoS on a single request. > > Sorry, I don't see what you mean - the hop counter can be tampered with > but a weighted coin can't, making it harder to influence how other nodes > handle the request. A lot more requests will naturally timeout than do now, and therefore a node can silently drop a request without arousing much concern or suspicion. Per node failure tables can't reroute that key until the timeout happens, and if the timeout is larger than it is now, that takes longer. > > > - The current counter is reset when we get closer to the target, so to some > > degree it adapts to the network size. We'd lose this, so we may have to set > > the probability of termination quite low, and fiddle with it... > > Good point, I didn't realise that resetting the counter had that function. > > > Why can we not analyse how much information the current counter leaks? Because > > of the uncertain topology/average number of resets? > > I shouldn't have said we can't analyse it, but I wouldn't know where to > start because so much depends on the topology. For example, the > closest-location-so-far obviously leaks information, but how do we > quantify it? Isn't it similar to the situation with keys? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/c21df9d9/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 00:08:57 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 00:08:57 +0000 Subject: [freenet-dev] Tunnels vs premix routing was Re: Vulnerability in inserting the manifest before finishing In-Reply-To: <47779AEF.6080305@cs.ucl.ac.uk> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210025.29457.toad@amphibian.dyndns.org> <47779AEF.6080305@cs.ucl.ac.uk> Message-ID: <200801030008.57919.toad@amphibian.dyndns.org> On Sunday 30 December 2007 13:19, Michael Rogers wrote: > > >> This could actually be used in place of premix routing: instead of > >> constructing cells we use random "tunnel IDs". > > > > No use against a local attacker. > > What kind of attack do you have in mind? "Local" = direct peer. If we use one tunnel per local pseudo-identity, it might work, but there is still a very high chance that the node sending the request is the originator. OTOH if we use more than one tunnel, either local collusion or rerouting may make life *much* easier for the attacker. > > > So a local attacker *immediately* knows that the keys are connected. > > Right, but who cares if the attacker knows that? The attacker doesn't > know whether you're the initiator of the tunnel. Makes it easier to track down the origin node for a swarm of requests once it reaches the request stage. Maybe that's not such a big deal. > > > This has been proposed before. One weakness is you'd need more than one tunnel > > to get good or predictable performance. And as soon as you have multiple > > correlatable or identical tunnels from the same node, it gets really easy to > > identify the requestor - admittedly it may require a conspiracy... > > The number of tunnels should be kept to a minimum to slow down > predecessor attacks (that's I2P's major weakness: tunnels are rebuilt > too frequently). 100 tunnels will give an attacker as much information > as 100 requests under the current system. > > On the other hand if you use separate tunnels for separate files then > it's harder for an attacker to link them, which makes it harder to use > them in a predecessor attack. So the initiator should choose tunnels > intelligently - eg give each client its own tunnel and each large > splitfile its own tunnel. For performance most users would likely want the node to use multiple tunnels for a single splitfile, and arguably this is a security issue: if the attacker receives the tunnel, and doesn't like its contents, he can trickle-feed it as an effective DoS. Note that an attacker in this case can be any node along the entire tunnel path, because they all know the keys. For premix routing, any effective attack requires that the tunnel exit node is owned by the attacker, and usually at least one node prior to that also. > > > Also, you have a very small anonymity set: if the tunnel is on average 5 hops > > long, there is a 20% chance that the node that sent you the request is the > > originator. This is unacceptable, especially if you can correlate the 20%'s > > because of linked but non-identical tunnels. > > True, but the same applies to premix routing: even if there are 100 > nodes in the cell, if you premix for 5 hops there's a 20% chance the > previous hop is the initiator. Misleading. :) If you are the exit node, you know there is a 1/cellSize chance the previous hop is the initiator. You can only know there is a high chance if you control both the exit node and a nonadjacent node before that, and you can tell that both are on the same chain. IMHO we can eliminate covert signalling, and without that all you have is the request timing, which may be enough, but will require a lot of requests to be sure of anything. Much superior to tunneling IMHO. > > > Finally, are there any vulnerabilities in changing paths? > > Yes - churn will force initiators to build new tunnels, speeding up the > predecessor attack. > > > Indeed, random hops seem to be the way forward. But if you get the request > > during the random hop phase, you can attack the originator, although it will > > take much more time than without random hops. > > Yup, there's no way to prevent predecessor attacks as far as I can tell, > but we can slow them down to one sample per tunnel instead of one sample > per request. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/795d78e5/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 00:11:55 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 00:11:55 +0000 Subject: [freenet-dev] Vulnerability in inserting the manifest before finishing In-Reply-To: <47779CB4.2050000@cs.ucl.ac.uk> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210139.35258.toad@amphibian.dyndns.org> <47779CB4.2050000@cs.ucl.ac.uk> Message-ID: <200801030011.55484.toad@amphibian.dyndns.org> On Sunday 30 December 2007 13:27, Michael Rogers wrote: > Matthew Toseland wrote: > > If you route randomly on each hop I'd > > expect to on average not get very far, because *most links are short links* > > on a small-world network. > > Yup, it's counter-intuitive because of clustering but small world > networks do have fast mixing times, ie short random walks will quickly > take you out of your local neighbourhood. Interesting. > > > On the other hand if you choose a random location > > and consistently route towards it you should have an equal chance of ending > > up anywhere on the network. > > Almost equal - the probability of ending up at a node is proportional to > the amount of keyspace it controls, which is somewhat unevenly > distributed even in an ideal network. Sure. > > > The catch is that if you route lots of requests > > to different random locations, and the attacker can connect the requests, he > > can gradually narrow down the locations you could have started in. > > True, and Borisov doesn't address this problem (which IMO is a major > one). As you know, my proposed solution is to reuse the same random path > for as long as possible (tunnels). Right. Despite my other posts, I'm not totally against tunnels, perhaps after premix routing. But IMHO we will need quite a few of them for good performance / reliability, even several for a single request group. > > > On a cell of 10,000 nodes, if on > > average each node goes down once a day, and this impacts on 10 other nodes, > > we have ~ 100,000 messages ... perhaps hundreds of megabytes, so it may be > > that cells this big are feasible. > > There's a tradeoff here: large cells provide a large anonymity set if > the attacker's outside the cell, but they make it more likely that > there's an attacker inside the cell who can attack key distribution etc. Sure, but inside the cell it's harder to attack than outside it, surely that is the whole point? Tor, I2P, Mixmaster and other traditional onion routers (apart from spanning tree impl's) use a whole-network cell. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/4fdda461/attachment.pgp From robert at emu.freenetproject.org Thu Jan 3 00:23:28 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Wed, 2 Jan 2008 18:23:28 -0600 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <200801022144.58447.toad@amphibian.dyndns.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> Message-ID: <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote: > On Wednesday 02 January 2008 17:22, Robert Hailey wrote: >> >> On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: >> >>>>> synchronized void updateShouldDisconnectNow() { >>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>>>> THE NODE >>>>> - if (isConnected()) { >>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || >>>>> verifiedIncompatibleNewerVersion) { >>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>>>> } >>>> >>>> I suggest you call isRoutable() instead >>>> >>>> NextGen$ >>> >>> Hmm, on a latter thought, I don't understand why it helps... nor why >>> we >>> are calling it from PacketSender >>> >>> What about getting rid of both the "if" branch and the call in >>> PacketSender ? >> >> In PacketSender this function is called ~precisely~ at the version >> transition time so that all peers will be re-evaluated concerning >> compatible versioning; this seems like an odd place to stick this >> code, but also updateShouldDisconnectNow() does not explicitly >> disconnect the peer node, it only updates the 'incompatible' flags. > > We don't want to disconnect. We want to stay connected and to not > route > requests to the node or accept them from it. We will still accept > e.g. Update > Over Mandatory traffic. Fair enough, but this is only confused semantics. I said disconnect as it is in the function name, perhaps a better name would be updateVersionRoutablity(). >> Concerning the if branch I added, the intended behaviour change is >> that this function should only (1) allow the disconnection of a >> connected peer by setting the incompatible flag, > > No, we don't want to disconnect. We just want to make it non- > routable, by > updating verified*. I used the wrong term. It will only update the verified* booleans (and thus make routable or not) if connected. But see below... >> Now, if the nodes can handshake, this code has probably has little >> effect, as it simply further restricts one of only two places that >> the >> incompatible flags are set (the other being on a handshake). What it >> will do is if the nodes can't talk to each other (like in my re-keyed >> node case), is not show 'TOO_OLD'/'TOO_NEW', but instead >> 'DISCONNECTED'. > > So you are setting verified* to false, because it's not verified? Not setting it to false, but... not allowing it to be set to true if that node cannot reach us (e.g. disconnected). >> And I suppose in the same error case... if the node is >> restarted, it would never be able to verify that the peer is too old/ >> new and fetch the ark (keeping the version number up-to-date). > > Again, we should always fetch the ARK. The original implementation appears to use verifiedIncompatible* to optimize against a time-based trigger (Version-Incompatibility) from a bunch of ark requests being started. On Jan 2, 2008, at 12:30 PM, David Sowder wrote: > I'm not sure of the thinking of others regarding changes to the > verifiedIncompatible variables since, but my thinking in my initial > implementation was that they would only be set after a handshake, thus > we already had a connected to them and ARKs weren't needed. That > won't > change until the peer re-handshakes after restarting with a different > version of the node's software. As best I can see, the verified* booleans have changed meanings since update-over-mandatory. If it is still useful to know if the peer node is presently-verified-{older/newer}, then we should split the booleans (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is an older (as Matthew suggested). In either case the misleading comments and variable names should be removed and/or changed. -- Robert Hailey From freenet-devl at david.sowder.com Thu Jan 3 00:45:48 2008 From: freenet-devl at david.sowder.com (David Sowder (Zothar)) Date: Wed, 02 Jan 2008 18:45:48 -0600 Subject: [freenet-dev] [freenet-cvs] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <200801022140.35033.toad@amphibian.dyndns.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <199BD599-D8DF-40FB-975B-2BF94854BF16@emu.freenetproject.org> <477BD863.50803@david.sowder.com> <200801022140.35033.toad@amphibian.dyndns.org> Message-ID: <477C303C.3040504@david.sowder.com> In my thinking, we should only change verifiedIncompatibleOlderVersion and verifiedIncompatibleNewerVersion in four situations, all of which may even mean that we call a function/method to check for the need to change in the code paths that are common to each of these situations: 1) Potentially set when we've just completed a handshake and therefore are connected and isConnected() is true (not necessarily isRoutable() for whatever reason) after which we have no need to fetch an ARK for the peer 2) Cleared if we are disconnecting (for whatever reason) from a peer that has had either verifiedIncompatibleOlderVersion or verifiedIncompatibleNewerVersion set, after which we may want to fetch an ARK for the peer just like we would if we had never connected to them since our last restart 3) Set verifiedIncompatibleOlderVersion when our node passes a mandatory threshold date and time 4) Set verifiedIncompatibleNewerVersion when the peer tells us we are too old for their idea of the mandatory threshold date and time (I don't recall by what mechanism this is accomplished ATM) Once verifiedIncompatibleOlderVersion or verifiedIncompatibleNewerVersion is set for a peer, it cannot be cleared by any means other than the peer reconnecting (either by a intermediate DISCONNECTED, etc. state or by boot ID change (if I understand that name/concept correctly)) after their restart or by our node's initializing the value to it's default False value on our node's restart. Caveat the above by the fact that I haven't read this related code in awhile, so I'm going by my memory of how it should work and what I remember of changes made by others since. Matthew Toseland wrote: > On Wednesday 02 January 2008 18:30, David Sowder wrote: > >> I'm not sure of the thinking of others regarding changes to the >> verifiedIncompatible variables since, but my thinking in my initial >> implementation was that they would only be set after a handshake, thus >> we already had a connected to them and ARKs weren't needed. That won't >> change until the peer re-handshakes after restarting with a different >> version of the node's software. >> > > I don't follow - clearly if isConnected(), we don't need the ARK. > > ------------------------------------------------------------------------ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl From freenet-devl at david.sowder.com Thu Jan 3 00:50:37 2008 From: freenet-devl at david.sowder.com (David Sowder (Zothar)) Date: Wed, 02 Jan 2008 18:50:37 -0600 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> Message-ID: <477C315D.8010609@david.sowder.com> To be clear, a TOO OLD/TOO NEW peer is currently connected in the sense that the node is exchanging traffic with it. The node just doesn't route any traffic through the peer and the traffic with the peer is limited to keeping the connectivity, N2NMs and UoM exchanges (I don't believe I'm forgetting anything, but it wouldn't be the first time). Robert Hailey wrote: > On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote: > > >> On Wednesday 02 January 2008 17:22, Robert Hailey wrote: >> >>> On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: >>> >>> >>>>>> synchronized void updateShouldDisconnectNow() { >>>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>>>>> THE NODE >>>>>> - if (isConnected()) { >>>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || >>>>>> verifiedIncompatibleNewerVersion) { >>>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>>>>> } >>>>>> >>>>> I suggest you call isRoutable() instead >>>>> >>>>> NextGen$ >>>>> >>>> Hmm, on a latter thought, I don't understand why it helps... nor why >>>> we >>>> are calling it from PacketSender >>>> >>>> What about getting rid of both the "if" branch and the call in >>>> PacketSender ? >>>> >>> In PacketSender this function is called ~precisely~ at the version >>> transition time so that all peers will be re-evaluated concerning >>> compatible versioning; this seems like an odd place to stick this >>> code, but also updateShouldDisconnectNow() does not explicitly >>> disconnect the peer node, it only updates the 'incompatible' flags. >>> >> We don't want to disconnect. We want to stay connected and to not >> route >> requests to the node or accept them from it. We will still accept >> e.g. Update >> Over Mandatory traffic. >> > > Fair enough, but this is only confused semantics. I said disconnect as > it is in the function name, perhaps a better name would be > updateVersionRoutablity(). > > >>> Concerning the if branch I added, the intended behaviour change is >>> that this function should only (1) allow the disconnection of a >>> connected peer by setting the incompatible flag, >>> >> No, we don't want to disconnect. We just want to make it non- >> routable, by >> updating verified*. >> > > I used the wrong term. It will only update the verified* booleans (and > thus make routable or not) if connected. But see below... > > >>> Now, if the nodes can handshake, this code has probably has little >>> effect, as it simply further restricts one of only two places that >>> the >>> incompatible flags are set (the other being on a handshake). What it >>> will do is if the nodes can't talk to each other (like in my re-keyed >>> node case), is not show 'TOO_OLD'/'TOO_NEW', but instead >>> 'DISCONNECTED'. >>> >> So you are setting verified* to false, because it's not verified? >> > > Not setting it to false, but... not allowing it to be set to true if > that node cannot reach us (e.g. disconnected). > > >>> And I suppose in the same error case... if the node is >>> restarted, it would never be able to verify that the peer is too old/ >>> new and fetch the ark (keeping the version number up-to-date). >>> >> Again, we should always fetch the ARK. >> > > The original implementation appears to use verifiedIncompatible* to > optimize against a time-based trigger (Version-Incompatibility) from a > bunch of ark requests being started. > > On Jan 2, 2008, at 12:30 PM, David Sowder wrote: > >> I'm not sure of the thinking of others regarding changes to the >> verifiedIncompatible variables since, but my thinking in my initial >> implementation was that they would only be set after a handshake, thus >> we already had a connected to them and ARKs weren't needed. That >> won't >> change until the peer re-handshakes after restarting with a different >> version of the node's software. >> > > As best I can see, the verified* booleans have changed meanings since > update-over-mandatory. If it is still useful to know if the peer node > is presently-verified-{older/newer}, then we should split the booleans > (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is > an older (as Matthew suggested). In either case the misleading > comments and variable names should be removed and/or changed. > > -- > Robert Hailey > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > From m.rogers at cs.ucl.ac.uk Thu Jan 3 01:17:19 2008 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 03 Jan 2008 01:17:19 +0000 Subject: [freenet-dev] One tunnel per request: justification In-Reply-To: <200801022352.54143.toad@amphibian.dyndns.org> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210025.29457.toad@amphibian.dyndns.org> <47779AEF.6080305@cs.ucl.ac.uk> <200801022352.54143.toad@amphibian.dyndns.org> Message-ID: <477C379F.4050706@cs.ucl.ac.uk> Matthew Toseland wrote: > - It should be possible with such a simple request/response to make it > extremely difficult for two nodes to realise they are on the same path, > except in the case where they are actually adjacent. I think that's optimistic - they could use the tunnel construction time, or the delay between the tunnel being constructed and used, or (for two-way tunnels) the delay between the request and the response. Let's say the attacker controls the exit node of tunnel X, and it normally takes 5 seconds to construct a tunnel. If an interesting request is sent through tunnel X, all the attacker's nodes record predecessor samples for any outgoing tunnels constructed in the 5 seconds before tunnel X was constructed, and successor samples for any incoming tunnels constructed in the 5 seconds after tunnel X was constructed. It doesn't matter that most of the samples are wrong - all that matters is that the initiator is more likely to be recorded than a random node (or a random member of the cell). If the attacker knows that tunnels always contain more than two nodes and don't pass through any node more than once, he can also eliminate samples from the exit node and its immediate neighbours. But that's not vital, it just reduces the level of noise. > However, it *is* > known that it is one of the nodes along that path that is the problem, and > this may be enough. Yup, if we can trust the topological information then we should be able to identify unreliable nodes and avoid using them in tunnels (but on the other hand that allows an attacker to attract more tunnels and thus gather more samples by performing well, as in I2P). > Each node publishes its links, including its pubkeys, their pubkey hashes, and > a signature. This is relayed to some distance. We compute a credibility value > for each node on the graph by starting with a value of 1.0 on each node we > are a direct peer of, and dividing it by the number of peers on each node > going outwards, adding up the values from different branches. We can then > ignore nodes which have a low credibility value. Sounds promising, but the result will be different from each node's point of view. How do we ensure that all members of the cell agree about which nodes to ignore? If they don't agree then it's easy for an attacker to calculate credibility values from every other node's point of view in order to work out who would or wouldn't have chosen a given exit node. > Now, we may not be able to > do exactly this, if we have to have semi-permanent cell structures, but it > should be possible to find an algorithm to serve this purpose (eigenvector > centrality? TrustRank etc?). We're caught in a cleft stick here: algorithms that give a universally agreed score for each node are vulnerable to Sybil attacks [1], but if a node's score depends on who evaluates it (eg the flow-based algorithm you sketched above) then how do we agree about which nodes to ignore? Cheers, Michael [1] http://www.sigcomm.org/sigcomm2005/paper-CheFri.pdf From m.rogers at cs.ucl.ac.uk Thu Jan 3 01:35:43 2008 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 03 Jan 2008 01:35:43 +0000 Subject: [freenet-dev] Why getting rid of HTL is bad was Re: Vulnerability in inserting the manifest before finishing In-Reply-To: <200801030000.13355.toad@amphibian.dyndns.org> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210025.29457.toad@amphibian.dyndns.org> <47779AEF.6080305@cs.ucl.ac.uk> <200801030000.13355.toad@amphibian.dyndns.org> Message-ID: <477C3BEF.9090308@cs.ucl.ac.uk> Matthew Toseland wrote: > No, but it would make the request time variance much higher, especially for > inserts and unsuccessful requests (which can potentially visit the entire > network). True, the variance would be higher. Visiting the entire network is a bit of an extreme example though - in theory it's also possible with the current hop counter, but it's not exactly likely. :-) > A lot more requests will naturally timeout than do now, and therefore a node > can silently drop a request without arousing much concern or suspicion. Per > node failure tables can't reroute that key until the timeout happens, and if > the timeout is larger than it is now, that takes longer. We're using a reliable transport between nodes, so the only things that should cause a timeout are overloaded, crashed or faulty nodes. If we can keep the ping time under control then we can detect crashed nodes quickly. So with proper load management we should be able to pretty much eliminate timeouts except in the case of faulty nodes, which can then be detected. >> I shouldn't have said we can't analyse it, but I wouldn't know where to >> start because so much depends on the topology. For example, the >> closest-location-so-far obviously leaks information, but how do we >> quantify it? > > Isn't it similar to the situation with keys? Sorry, I don't follow. The closest-location-so-far tells an attacker something about the path a request has followed - among other things, it allows the attacker to rule out certain nodes the request definitely hasn't passed through. But how would we quantify that in terms of the size of the initiator's anonymity set or the probability that a given node is the initiator, for example? Whereas with a weighted coin, if the probability that each node terminates the request is 1/n then there's a 1/n chance that the previous hop is the initiator. Cheers, Michael From m.rogers at cs.ucl.ac.uk Thu Jan 3 01:49:20 2008 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 03 Jan 2008 01:49:20 +0000 Subject: [freenet-dev] Tunnels vs premix routing was Re: Vulnerability in inserting the manifest before finishing In-Reply-To: <200801030008.57919.toad@amphibian.dyndns.org> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210025.29457.toad@amphibian.dyndns.org> <47779AEF.6080305@cs.ucl.ac.uk> <200801030008.57919.toad@amphibian.dyndns.org> Message-ID: <477C3F20.7070208@cs.ucl.ac.uk> Matthew Toseland wrote: > "Local" = direct peer. If we use one tunnel per local pseudo-identity, it > might work, but there is still a very high chance that the node sending the > request is the originator. Right, but that's also the case at the moment: if requests travel n hops on average then there's a 1/n chance that the previous hop is the initiator. I don't see how you can get away from that without onion routing. > OTOH if we use more than one tunnel, either local > collusion or rerouting may make life *much* easier for the attacker. Yes, we should keep the number of linkable tunnels to a minimum. > Makes it easier to track down the origin node for a swarm of requests once it > reaches the request stage. Maybe that's not such a big deal. If tunnels do their job then it doesn't matter if an attacker can find the last node in the tunnel. > For performance most users would likely want the node to use multiple tunnels > for a single splitfile, and arguably this is a security issue: if the > attacker receives the tunnel, and doesn't like its contents, he can > trickle-feed it as an effective DoS. Users who value performance over anonymity could use multiple tunnels per splitfile and/or shorter tunnels. I'm just saying that for maximum anonymity, the tunnels should be long enough that any node could be the initiator, and the number of linkable tunnels should be minimised (eg one tunnel per Frost ID per session rather than one per message). > For > premix routing, any effective attack requires that the tunnel exit node is > owned by the attacker, and usually at least one node prior to that also. True, I'm not suggesting that tunnels are as strong as premix routing, but on the other hand they don't require revealing the topology or distributing (and agreeing on) public keys for every node in the cell. Cheers, Michael From m.rogers at cs.ucl.ac.uk Thu Jan 3 02:07:19 2008 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Thu, 03 Jan 2008 02:07:19 +0000 Subject: [freenet-dev] Vulnerability in inserting the manifest before finishing In-Reply-To: <200801030011.55484.toad@amphibian.dyndns.org> References: <200712192256.08351.toad@amphibian.dyndns.org> <200712210139.35258.toad@amphibian.dyndns.org> <47779CB4.2050000@cs.ucl.ac.uk> <200801030011.55484.toad@amphibian.dyndns.org> Message-ID: <477C4357.6020805@cs.ucl.ac.uk> Matthew Toseland wrote: >> There's a tradeoff here: large cells provide a large anonymity set if >> the attacker's outside the cell, but they make it more likely that >> there's an attacker inside the cell who can attack key distribution etc. > > Sure, but inside the cell it's harder to attack than outside it, surely that > is the whole point? Tor, I2P, Mixmaster and other traditional onion routers > (apart from spanning tree impl's) use a whole-network cell. Right, but they all fudge the key distribution problem. Tor and Mixminion use central directory servers; I2P uses a DHT made of untrusted nodes; Tarzan uses an insecure and unscalable gossip protocol; MorphMix uses an insecure collusion detection mechanism [1]. I understand why premix routing is preferable to tunnels but you have to solve the key distribution problem - your credibility score proposal sounds promising but I'm not sure it's possible to make it Sybilproof and still ensure that all nodes agree about the topology. Cheers, Michael [1] http://www.crhc.uiuc.edu/~nikita/papers/pet2006-morphmix.pdf From nextgens at freenetproject.org Thu Jan 3 10:18:37 2008 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 3 Jan 2008 11:18:37 +0100 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> Message-ID: <20080103101836.GA4339@freenetproject.org> * Robert Hailey [2008-01-02 18:23:28]: > > On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote: > > > On Wednesday 02 January 2008 17:22, Robert Hailey wrote: > >> > >> On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: > >> > >>>>> synchronized void updateShouldDisconnectNow() { > >>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH > >>>>> THE NODE > >>>>> - if (isConnected()) { > >>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || > >>>>> verifiedIncompatibleNewerVersion) { > >>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > >>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > >>>>> } > >>>> > >>>> I suggest you call isRoutable() instead > >>>> > >>>> NextGen$ > >>> > >>> Hmm, on a latter thought, I don't understand why it helps... nor why > >>> we > >>> are calling it from PacketSender > >>> > >>> What about getting rid of both the "if" branch and the call in > >>> PacketSender ? > >> > >> In PacketSender this function is called ~precisely~ at the version > >> transition time so that all peers will be re-evaluated concerning > >> compatible versioning; this seems like an odd place to stick this > >> code, but also updateShouldDisconnectNow() does not explicitly > >> disconnect the peer node, it only updates the 'incompatible' flags. > > > > We don't want to disconnect. We want to stay connected and to not > > route > > requests to the node or accept them from it. We will still accept > > e.g. Update > > Over Mandatory traffic. > > Fair enough, but this is only confused semantics. I said disconnect as > it is in the function name, perhaps a better name would be > updateVersionRoutablity(). > > >> Concerning the if branch I added, the intended behaviour change is > >> that this function should only (1) allow the disconnection of a > >> connected peer by setting the incompatible flag, > > > > No, we don't want to disconnect. We just want to make it non- > > routable, by > > updating verified*. > > I used the wrong term. It will only update the verified* booleans (and > thus make routable or not) if connected. But see below... > > >> Now, if the nodes can handshake, this code has probably has little > >> effect, as it simply further restricts one of only two places that > >> the > >> incompatible flags are set (the other being on a handshake). What it > >> will do is if the nodes can't talk to each other (like in my re-keyed > >> node case), is not show 'TOO_OLD'/'TOO_NEW', but instead > >> 'DISCONNECTED'. > > > > So you are setting verified* to false, because it's not verified? > > Not setting it to false, but... not allowing it to be set to true if > that node cannot reach us (e.g. disconnected). > > >> And I suppose in the same error case... if the node is > >> restarted, it would never be able to verify that the peer is too old/ > >> new and fetch the ark (keeping the version number up-to-date). > > > > Again, we should always fetch the ARK. > > The original implementation appears to use verifiedIncompatible* to > optimize against a time-based trigger (Version-Incompatibility) from a > bunch of ark requests being started. > > On Jan 2, 2008, at 12:30 PM, David Sowder wrote: > > I'm not sure of the thinking of others regarding changes to the > > verifiedIncompatible variables since, but my thinking in my initial > > implementation was that they would only be set after a handshake, thus > > we already had a connected to them and ARKs weren't needed. That > > won't > > change until the peer re-handshakes after restarting with a different > > version of the node's software. > > As best I can see, the verified* booleans have changed meanings since > update-over-mandatory. If it is still useful to know if the peer node > is presently-verified-{older/newer}, then we should split the booleans > (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is > an older (as Matthew suggested). In either case the misleading > comments and variable names should be removed and/or changed. We want to fetch ARKs in any case imo. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/0a0bd17f/attachment.pgp From freenet-devl at david.sowder.com Thu Jan 3 13:36:39 2008 From: freenet-devl at david.sowder.com (David Sowder) Date: Thu, 03 Jan 2008 07:36:39 -0600 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <20080103101836.GA4339@freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> <20080103101836.GA4339@freenetproject.org> Message-ID: <477CE4E7.5020700@david.sowder.com> Florent Daigni?re wrote: > * Robert Hailey [2008-01-02 18:23:28]: > > >> On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote: >> >> >>> On Wednesday 02 January 2008 17:22, Robert Hailey wrote: >>> >>>> On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: >>>> >>>> >>>>>>> synchronized void updateShouldDisconnectNow() { >>>>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>>>>>> THE NODE >>>>>>> - if (isConnected()) { >>>>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || >>>>>>> verifiedIncompatibleNewerVersion) { >>>>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>>>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>>>>>> } >>>>>>> >>>>>> I suggest you call isRoutable() instead >>>>>> >>>>>> NextGen$ >>>>>> >>>>> Hmm, on a latter thought, I don't understand why it helps... nor why >>>>> we >>>>> are calling it from PacketSender >>>>> >>>>> What about getting rid of both the "if" branch and the call in >>>>> PacketSender ? >>>>> >>>> In PacketSender this function is called ~precisely~ at the version >>>> transition time so that all peers will be re-evaluated concerning >>>> compatible versioning; this seems like an odd place to stick this >>>> code, but also updateShouldDisconnectNow() does not explicitly >>>> disconnect the peer node, it only updates the 'incompatible' flags. >>>> >>> We don't want to disconnect. We want to stay connected and to not >>> route >>> requests to the node or accept them from it. We will still accept >>> e.g. Update >>> Over Mandatory traffic. >>> >> Fair enough, but this is only confused semantics. I said disconnect as >> it is in the function name, perhaps a better name would be >> updateVersionRoutablity(). >> >> >>>> Concerning the if branch I added, the intended behaviour change is >>>> that this function should only (1) allow the disconnection of a >>>> connected peer by setting the incompatible flag, >>>> >>> No, we don't want to disconnect. We just want to make it non- >>> routable, by >>> updating verified*. >>> >> I used the wrong term. It will only update the verified* booleans (and >> thus make routable or not) if connected. But see below... >> >> >>>> Now, if the nodes can handshake, this code has probably has little >>>> effect, as it simply further restricts one of only two places that >>>> the >>>> incompatible flags are set (the other being on a handshake). What it >>>> will do is if the nodes can't talk to each other (like in my re-keyed >>>> node case), is not show 'TOO_OLD'/'TOO_NEW', but instead >>>> 'DISCONNECTED'. >>>> >>> So you are setting verified* to false, because it's not verified? >>> >> Not setting it to false, but... not allowing it to be set to true if >> that node cannot reach us (e.g. disconnected). >> >> >>>> And I suppose in the same error case... if the node is >>>> restarted, it would never be able to verify that the peer is too old/ >>>> new and fetch the ark (keeping the version number up-to-date). >>>> >>> Again, we should always fetch the ARK. >>> >> The original implementation appears to use verifiedIncompatible* to >> optimize against a time-based trigger (Version-Incompatibility) from a >> bunch of ark requests being started. >> >> On Jan 2, 2008, at 12:30 PM, David Sowder wrote: >> >>> I'm not sure of the thinking of others regarding changes to the >>> verifiedIncompatible variables since, but my thinking in my initial >>> implementation was that they would only be set after a handshake, thus >>> we already had a connected to them and ARKs weren't needed. That >>> won't >>> change until the peer re-handshakes after restarting with a different >>> version of the node's software. >>> >> As best I can see, the verified* booleans have changed meanings since >> update-over-mandatory. If it is still useful to know if the peer node >> is presently-verified-{older/newer}, then we should split the booleans >> (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is >> an older (as Matthew suggested). In either case the misleading >> comments and variable names should be removed and/or changed. >> > > We want to fetch ARKs in any case imo. > And in my opinion, fetching an ARK for a connected peer is pointless, but perhaps we agree in our assessments and I misunderstand by thinking you mean to _always_ fetch ARKs regardless of current peer status. From nextgens at freenetproject.org Thu Jan 3 13:44:33 2008 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 3 Jan 2008 14:44:33 +0100 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <477CE4E7.5020700@david.sowder.com> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> <20080103101836.GA4339@freenetproject.org> <477CE4E7.5020700@david.sowder.com> Message-ID: <20080103134433.GC4339@freenetproject.org> * David Sowder [2008-01-03 07:36:39]: > Florent Daigni?re wrote: >> * Robert Hailey [2008-01-02 18:23:28]: >> >> >>> On Jan 2, 2008, at 3:44 PM, Matthew Toseland wrote: >>> >>> >>>> On Wednesday 02 January 2008 17:22, Robert Hailey wrote: >>>> >>>>> On Dec 29, 2007, at 5:39 AM, Florent Daigni?re wrote: >>>>> >>>>> >>>>>>>> synchronized void updateShouldDisconnectNow() { >>>>>>>> //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH >>>>>>>> THE NODE >>>>>>>> - if (isConnected()) { >>>>>>>> + if (isConnected() || verifiedIncompatibleOlderVersion || >>>>>>>> verifiedIncompatibleNewerVersion) { >>>>>>>> verifiedIncompatibleOlderVersion = forwardInvalidVersion(); >>>>>>>> verifiedIncompatibleNewerVersion = reverseInvalidVersion(); >>>>>>>> } >>>>>>>> >>>>>>> I suggest you call isRoutable() instead >>>>>>> >>>>>>> NextGen$ >>>>>>> >>>>>> Hmm, on a latter thought, I don't understand why it helps... nor why >>>>>> we >>>>>> are calling it from PacketSender >>>>>> >>>>>> What about getting rid of both the "if" branch and the call in >>>>>> PacketSender ? >>>>>> >>>>> In PacketSender this function is called ~precisely~ at the version >>>>> transition time so that all peers will be re-evaluated concerning >>>>> compatible versioning; this seems like an odd place to stick this >>>>> code, but also updateShouldDisconnectNow() does not explicitly >>>>> disconnect the peer node, it only updates the 'incompatible' flags. >>>>> >>>> We don't want to disconnect. We want to stay connected and to not route >>>> requests to the node or accept them from it. We will still accept e.g. >>>> Update >>>> Over Mandatory traffic. >>>> >>> Fair enough, but this is only confused semantics. I said disconnect as >>> it is in the function name, perhaps a better name would be >>> updateVersionRoutablity(). >>> >>> >>>>> Concerning the if branch I added, the intended behaviour change is >>>>> that this function should only (1) allow the disconnection of a >>>>> connected peer by setting the incompatible flag, >>>>> >>>> No, we don't want to disconnect. We just want to make it non- routable, >>>> by >>>> updating verified*. >>>> >>> I used the wrong term. It will only update the verified* booleans (and >>> thus make routable or not) if connected. But see below... >>> >>> >>>>> Now, if the nodes can handshake, this code has probably has little >>>>> effect, as it simply further restricts one of only two places that the >>>>> incompatible flags are set (the other being on a handshake). What it >>>>> will do is if the nodes can't talk to each other (like in my re-keyed >>>>> node case), is not show 'TOO_OLD'/'TOO_NEW', but instead >>>>> 'DISCONNECTED'. >>>>> >>>> So you are setting verified* to false, because it's not verified? >>>> >>> Not setting it to false, but... not allowing it to be set to true if >>> that node cannot reach us (e.g. disconnected). >>> >>> >>>>> And I suppose in the same error case... if the node is >>>>> restarted, it would never be able to verify that the peer is too old/ >>>>> new and fetch the ark (keeping the version number up-to-date). >>>>> >>>> Again, we should always fetch the ARK. >>>> >>> The original implementation appears to use verifiedIncompatible* to >>> optimize against a time-based trigger (Version-Incompatibility) from a >>> bunch of ark requests being started. >>> >>> On Jan 2, 2008, at 12:30 PM, David Sowder wrote: >>> >>>> I'm not sure of the thinking of others regarding changes to the >>>> verifiedIncompatible variables since, but my thinking in my initial >>>> implementation was that they would only be set after a handshake, thus >>>> we already had a connected to them and ARKs weren't needed. That won't >>>> change until the peer re-handshakes after restarting with a different >>>> version of the node's software. >>>> >>> As best I can see, the verified* booleans have changed meanings since >>> update-over-mandatory. If it is still useful to know if the peer node is >>> presently-verified-{older/newer}, then we should split the booleans >>> (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is an >>> older (as Matthew suggested). In either case the misleading comments and >>> variable names should be removed and/or changed. >>> >> >> We want to fetch ARKs in any case imo. >> > And in my opinion, fetching an ARK for a connected peer is pointless, but > perhaps we agree in our assessments and I misunderstand by thinking you > mean to _always_ fetch ARKs regardless of current peer status. It's not pointless. We want to keep an up to date "edition" for the ark so that when we will need it we will be able to reach it... Of course we could exchange and update the edition number on handshake... but atm we don't. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/851bc578/attachment.pgp From freenet-devl at david.sowder.com Thu Jan 3 13:52:44 2008 From: freenet-devl at david.sowder.com (David Sowder) Date: Thu, 03 Jan 2008 07:52:44 -0600 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <20080103134433.GC4339@freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> <20080103101836.GA4339@freenetproject.org> <477CE4E7.5020700@david.sowder.com> <20080103134433.GC4339@freenetproject.org> Message-ID: <477CE8AC.9080307@david.sowder.com> Florent Daigni?re wrote: > * David Sowder [2008-01-03 07:36:39]: > > >> Florent Daigni?re wrote: >> >>> * Robert Hailey [2008-01-02 18:23:28]: >>> >>>> >>>> On Jan 2, 2008, at 12:30 PM, David Sowder wrote: >>>> >>>> >>>>> I'm not sure of the thinking of others regarding changes to the >>>>> verifiedIncompatible variables since, but my thinking in my initial >>>>> implementation was that they would only be set after a handshake, thus >>>>> we already had a connected to them and ARKs weren't needed. That won't >>>>> change until the peer re-handshakes after restarting with a different >>>>> version of the node's software. >>>>> >>>>> >>>> As best I can see, the verified* booleans have changed meanings since >>>> update-over-mandatory. If it is still useful to know if the peer node is >>>> presently-verified-{older/newer}, then we should split the booleans >>>> (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is an >>>> older (as Matthew suggested). In either case the misleading comments and >>>> variable names should be removed and/or changed. >>>> >>>> >>> We want to fetch ARKs in any case imo. >>> >>> >> And in my opinion, fetching an ARK for a connected peer is pointless, but >> perhaps we agree in our assessments and I misunderstand by thinking you >> mean to _always_ fetch ARKs regardless of current peer status. >> > > It's not pointless. We want to keep an up to date "edition" for the ark so > that when we will need it we will be able to reach it... Of course we > could exchange and update the edition number on handshake... but atm we > don't. > It is pointless. If the problem is that we don't have updated ARK edition numbers, then we should fix that by exchanging that across an existing connection when we have one rather than forcing the use of a backwards and network load causing method for for information we have from a directly connected peer. Fixing that is simply a matter of exchanging either full or differential references with our peers any time our node's reference changes. I'm not exactly available to implement it right now, but I know for a fact that this is not a hard problem to solve. In fact, differential references could be trivially implemented using the existing N2NM messaging facilities. From nextgens at freenetproject.org Thu Jan 3 13:57:24 2008 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 3 Jan 2008 14:57:24 +0100 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <477CE8AC.9080307@david.sowder.com> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> <20080103101836.GA4339@freenetproject.org> <477CE4E7.5020700@david.sowder.com> <20080103134433.GC4339@freenetproject.org> <477CE8AC.9080307@david.sowder.com> Message-ID: <20080103135723.GD4339@freenetproject.org> * David Sowder [2008-01-03 07:52:44]: > Florent Daigni?re wrote: >> * David Sowder [2008-01-03 07:36:39]: >> >> >>> Florent Daigni?re wrote: >>> >>>> * Robert Hailey [2008-01-02 18:23:28]: >>>> >>>>> >>>>> On Jan 2, 2008, at 12:30 PM, David Sowder wrote: >>>>> >>>>>> I'm not sure of the thinking of others regarding changes to the >>>>>> verifiedIncompatible variables since, but my thinking in my initial >>>>>> implementation was that they would only be set after a handshake, thus >>>>>> we already had a connected to them and ARKs weren't needed. That won't >>>>>> change until the peer re-handshakes after restarting with a different >>>>>> version of the node's software. >>>>>> >>>>> As best I can see, the verified* booleans have changed meanings since >>>>> update-over-mandatory. If it is still useful to know if the peer node >>>>> is presently-verified-{older/newer}, then we should split the booleans >>>>> (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is >>>>> an older (as Matthew suggested). In either case the misleading >>>>> comments and variable names should be removed and/or changed. >>>>> >>>> We want to fetch ARKs in any case imo. >>>> >>> And in my opinion, fetching an ARK for a connected peer is pointless, but >>> perhaps we agree in our assessments and I misunderstand by thinking you >>> mean to _always_ fetch ARKs regardless of current peer status. >>> >> >> It's not pointless. We want to keep an up to date "edition" for the ark so >> that when we will need it we will be able to reach it... Of course we >> could exchange and update the edition number on handshake... but atm we >> don't. >> > It is pointless. If the problem is that we don't have updated ARK edition > numbers, then we should fix that by exchanging that across an existing > connection when we have one rather than forcing the use of a backwards and > network load causing method for for information we have from a directly > connected peer. It has at least two assets : 1) code simplicity 2) it propagates the ARK > Fixing that is simply a matter of exchanging either full > or differential references with our peers any time our node's reference > changes. Lots of things are that simple and in need of doing because noone is available to implement them. > I'm not exactly available to implement it right now, but I know > for a fact that this is not a hard problem to solve. Neither am I > In fact, differential > references could be trivially implemented using the existing N2NM messaging > facilities. Creating a new DMT message type or extending an existing one is the way to go. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/b219de47/attachment.pgp From freenet-devl at david.sowder.com Thu Jan 3 14:33:00 2008 From: freenet-devl at david.sowder.com (David Sowder) Date: Thu, 03 Jan 2008 08:33:00 -0600 Subject: [freenet-dev] r16834 - trunk/freenet/src/freenet/node In-Reply-To: <20080103135723.GD4339@freenetproject.org> References: <20071229014631.C5D7847A6AE@freenetproject.org> <20071229113933.GD4199@freenetproject.org> <200801022144.58447.toad@amphibian.dyndns.org> <010C7EF2-50D3-4E08-AC05-7F1F4E281FB0@emu.freenetproject.org> <20080103101836.GA4339@freenetproject.org> <477CE4E7.5020700@david.sowder.com> <20080103134433.GC4339@freenetproject.org> <477CE8AC.9080307@david.sowder.com> <20080103135723.GD4339@freenetproject.org> Message-ID: <477CF21C.7000301@david.sowder.com> Florent Daigni?re wrote: > * David Sowder [2008-01-03 07:52:44]: > > >> Florent Daigni?re wrote: >> >>> * David Sowder [2008-01-03 07:36:39]: >>> >>> >>> >>>> Florent Daigni?re wrote: >>>> >>>> >>>>> * Robert Hailey [2008-01-02 18:23:28]: >>>>> >>>>> >>>>>> On Jan 2, 2008, at 12:30 PM, David Sowder wrote: >>>>>> >>>>>> >>>>>>> I'm not sure of the thinking of others regarding changes to the >>>>>>> verifiedIncompatible variables since, but my thinking in my initial >>>>>>> implementation was that they would only be set after a handshake, thus >>>>>>> we already had a connected to them and ARKs weren't needed. That won't >>>>>>> change until the peer re-handshakes after restarting with a different >>>>>>> version of the node's software. >>>>>>> >>>>>>> >>>>>> As best I can see, the verified* booleans have changed meanings since >>>>>> update-over-mandatory. If it is still useful to know if the peer node >>>>>> is presently-verified-{older/newer}, then we should split the booleans >>>>>> (isOlder,isVerifiedOlder); otherwise just fetch an ark even if it is >>>>>> an older (as Matthew suggested). In either case the misleading >>>>>> comments and variable names should be removed and/or changed. >>>>>> >>>>>> >>>>> We want to fetch ARKs in any case imo. >>>>> >>>>> >>>> And in my opinion, fetching an ARK for a connected peer is pointless, but >>>> perhaps we agree in our assessments and I misunderstand by thinking you >>>> mean to _always_ fetch ARKs regardless of current peer status. >>>> >>>> >>> It's not pointless. We want to keep an up to date "edition" for the ark so >>> that when we will need it we will be able to reach it... Of course we >>> could exchange and update the edition number on handshake... but atm we >>> don't. >>> >>> >> It is pointless. If the problem is that we don't have updated ARK edition >> numbers, then we should fix that by exchanging that across an existing >> connection when we have one rather than forcing the use of a backwards and >> network load causing method for for information we have from a directly >> connected peer. >> > > It has at least two assets : 1) code simplicity 2) it propagates the ARK > IMO, both 1 and 2 are outweighed by the network load of all nodes constantly fetching ARKs for all of their peers network-wide. 1) IMO, this is a flimsy argument considering that there are many parts of the Freenet code base that are much more complex than what I'm talking about would require and many of them, while perhaps they could be simpler, have to be somewhat complex by necessity. 2) Fetching the ARK on first connect and some number of minutes or hours after the peer tells us via differential references that it has changed would have a much more gentle impact on network load. It could be argued that if ARKs aren't propagating from their inserts correctly, there is a routing issue. If we're worried about the ARK falling out of the network, we could fetch it once every seven days after it's last change. >> Fixing that is simply a matter of exchanging either full >> or differential references with our peers any time our node's reference >> changes. >> > > Lots of things are that simple and in need of doing because noone is > available to implement them. > Perhaps this one interests me enough to code up if I'm in the right mood after work some day in the coming weeks. I'll probably implement it on top of N2NMs since they were designed to be generic and I see no reason not to use them as they already support sending arbitrary SFS blocks. >> I'm not exactly available to implement it right now, but I know >> for a fact that this is not a hard problem to solve. >> > > Neither am I > > >> In fact, differential >> references could be trivially implemented using the existing N2NM messaging >> facilities. >> > > Creating a new DMT message type or extending an existing one is the way > to go. > From toad at amphibian.dyndns.org Thu Jan 3 15:03:29 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 15:03:29 +0000 Subject: [freenet-dev] [freenet-cvs] r16817 - in trunk/freenet/src/freenet: node support/math In-Reply-To: <20071226205138.AA33B47A371@freenetproject.org> References: <20071226205138.AA33B47A371@freenetproject.org> Message-ID: <200801031503.34926.toad@amphibian.dyndns.org> Useful class, but I'm really not convinced it's statistically sound. You need to normalize the stored value after every operation, otherwise as it gets larger, you will get bigger jumps when values are reported. In order to do this, you probably need to extend BDRA; put some hooks in. On Wednesday 26 December 2007 20:51, robert at freenetproject.org wrote: > Author: robert > Date: 2007-12-26 20:51:38 +0000 (Wed, 26 Dec 2007) > New Revision: 16817 > > Added: > trunk/freenet/src/freenet/support/math/DecayingKeyspaceAverage.java > Modified: > trunk/freenet/src/freenet/node/Location.java > trunk/freenet/src/freenet/node/NodeStats.java > Log: > implement keyspace-aware averager > > > Modified: trunk/freenet/src/freenet/node/Location.java > =================================================================== > --- trunk/freenet/src/freenet/node/Location.java 2007-12-26 20:48:13 UTC (rev 16816) > +++ trunk/freenet/src/freenet/node/Location.java 2007-12-26 20:51:38 UTC (rev 16817) > @@ -70,6 +70,20 @@ > } > } > > + /** > + * Given an arbitrary double (not bound to [0.0, 1.0]) return the normalized double [0.0, 1.0] which would result in simple > + * wrapping/overflowing. e.g. normalize(1.0+0.5)==0.5, normalize(0.5-1.0)==0.5, normalize({0.0,1.0})=={0.0,1.0} > + * @bug: if given double has wrapped too many times, the return value may be not be precise. > + */ > + public static double normalize(double rough) { > + int intPart=(int)rough; > + double maybeNegative=rough-intPart; > + //note: maybeNegative is bound between (-1.0, 1.0) > + if (maybeNegative < 0) > + return 1.0+maybeNegative; > + return maybeNegative; > + } > + > public static boolean equals(double newLoc, double currentLocation) { > return Math.abs(newLoc - currentLocation) < Double.MIN_VALUE * 2; > } > > Modified: trunk/freenet/src/freenet/node/NodeStats.java > =================================================================== > --- trunk/freenet/src/freenet/node/NodeStats.java 2007-12-26 20:48:13 UTC (rev 16816) > +++ trunk/freenet/src/freenet/node/NodeStats.java 2007-12-26 20:51:38 UTC (rev 16817) > @@ -23,6 +23,7 @@ > import freenet.support.api.IntCallback; > import freenet.support.api.LongCallback; > import freenet.support.math.BootstrappingDecayingRunningAverage; > +import freenet.support.math.DecayingKeyspaceAverage; > import freenet.support.math.RunningAverage; > import freenet.support.math.TimeDecayingRunningAverage; > import freenet.support.math.TrivialRunningAverage; > @@ -189,11 +190,11 @@ > this.backedOffPercent = new TimeDecayingRunningAverage(0.0, 180000, 0.0, 1.0, node); > double nodeLoc=node.lm.getLocation(); > // FIXME PLEASE; (int) casts; (maxCacheKeys>MAXINT?) This value will probably end up being a small constant anyway (200?). > - this.avgCacheLocation = new BootstrappingDecayingRunningAverage(nodeLoc, 0.0, 1.0, (int)node.maxCacheKeys, null); > - this.avgStoreLocation = new BootstrappingDecayingRunningAverage(nodeLoc, 0.0, 1.0, (int)node.maxStoreKeys, null); > - this.avgCacheSuccess = new BootstrappingDecayingRunningAverage(nodeLoc, 0.0, 1.0, 10000, null); > - this.avgStoreSuccess = new BootstrappingDecayingRunningAverage(nodeLoc, 0.0, 1.0, 10000, null); > - this.avgRequestLocation = new BootstrappingDecayingRunningAverage(nodeLoc, 0.0, 1.0, 10000, null); > + this.avgCacheLocation = new DecayingKeyspaceAverage(nodeLoc, (int)node.maxCacheKeys, null); > + this.avgStoreLocation = new DecayingKeyspaceAverage(nodeLoc, (int)node.maxStoreKeys, null); > + this.avgCacheSuccess = new DecayingKeyspaceAverage(nodeLoc, 10000, null); > + this.avgStoreSuccess = new DecayingKeyspaceAverage(nodeLoc, 10000, null); > + this.avgRequestLocation = new DecayingKeyspaceAverage(nodeLoc, 10000, null); > preemptiveRejectReasons = new StringCounter(); > localPreemptiveRejectReasons = new StringCounter(); > pInstantRejectIncoming = new TimeDecayingRunningAverage(0, 60000, 0.0, 1.0, node); > > Added: trunk/freenet/src/freenet/support/math/DecayingKeyspaceAverage.java > =================================================================== > --- trunk/freenet/src/freenet/support/math/DecayingKeyspaceAverage.java (rev 0) > +++ trunk/freenet/src/freenet/support/math/DecayingKeyspaceAverage.java 2007-12-26 20:51:38 UTC (rev 16817) > @@ -0,0 +1,139 @@ > +/* This code is part of Freenet. It is distributed under the GNU General > + * Public License, version 2 (or at your option any later version). See > + * http://www.gnu.org/ for further details of the GPL. */ > +package freenet.support.math; > + > +import freenet.node.Location; > + > +import freenet.support.Logger; > +import freenet.support.SimpleFieldSet; > + > +/** > + * @author robert > + * > + * A filter on BootstrappingDecayingRunningAverage which makes it aware of the circular keyspace. > + */ > +public class DecayingKeyspaceAverage implements RunningAverage { > + /** > + 'avg' is the non-normalized average location. > + */ > + BootstrappingDecayingRunningAverage avg; > + > + //If the keyspace averager wraps more than this number of times, an exception will be thrown. > + public final static int WRAP_WARNING=1000; > + > + public DecayingKeyspaceAverage(double defaultValue, int maxReports, SimpleFieldSet fs) { > + avg=new BootstrappingDecayingRunningAverage(defaultValue, -WRAP_WARNING, WRAP_WARNING, maxReports, fs); > + } > + > + public DecayingKeyspaceAverage(BootstrappingDecayingRunningAverage a) { > + //check the max/min values? ignore them? > + avg=(BootstrappingDecayingRunningAverage)a.clone(); > + } > + > + public synchronized Object clone() { > + return new DecayingKeyspaceAverage(avg); > + } > + > + public synchronized double currentValue() { > + return Location.normalize(avg.currentValue()); > + } > + > + public synchronized void report(double d) { > + if ((d < 0.0) || (d > 1.0)) { > + //Just because we use non-normalized locations doesn't mean we can accept them. > + throw new IllegalArgumentException("Not a valid normalized key: "+d); > + } > + double superValue=avg.currentValue(); > + double thisValue=Location.normalize(superValue); > + double diff=Location.change(thisValue, d); > + double toAverage=(superValue+diff); > + /* > + To gracefully wrap around the 1.0/0.0 threshold we average over (or under) it, and simply normalize the result when reporting a currentValue > + ---example--- > + d=0.2; //being reported > + superValue=1.9; //already wrapped once, but at 0.9 > + thisValue=0.9; //the normalized value of where we are in the keyspace > + diff = +0.3; //the diff from the normalized values; Location.change(0.9, 0.2); > + avg.report(2.2);//to successfully move the average towards the closest route to the given value. > + */ > + //System.err.println("debug: "+superValue+", "+thisValue+", "+diff+", "+(superValue+diff)+", "+Location.normalize(superValue+diff)); > + if (toAverage>WRAP_WARNING || toAverage<-WRAP_WARNING) > + Logger.error(this, "DecayingKeyspaceAverage is wrapped up too many times"); > + avg.report(toAverage); > + } > + > + public synchronized double valueIfReported(double d) { > + if ((d < 0.0) || (d > 1.0)) { > + throw new IllegalArgumentException("Not a valid normalized key: "+d); > + } > + double superValue=avg.currentValue(); > + double thisValue=Location.normalize(superValue); > + double diff=Location.change(thisValue, d); > + return avg.valueIfReported(superValue+diff); > + } > + > + public synchronized long countReports() { > + return avg.countReports(); > + } > + > + public void report(long d) { > + throw new IllegalArgumentException("KeyspaceAverage does not like longs"); > + } > + > + ///@todo: make this a junit test > + public static void main(String[] args) { > + DecayingKeyspaceAverage a=new DecayingKeyspaceAverage(0.9, 10, null); > + a.report(0.9); > + for (int i=10; i!=0; i--) { > + a.report(0.2); > + System.out.println("<-0.2-- current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(0.8); > + System.out.println("--0.8-> current="+a.currentValue()); > + } > + System.out.println("--- positive wrap test ---"); > + for (int wrap=3; wrap!=0; wrap--) { > + System.out.println("wrap test #"+wrap); > + for (int i=10; i!=0; i--) { > + a.report(0.25); > + System.out.println("<-0.25- current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(0.5); > + System.out.println("--0.5-> current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(0.75); > + System.out.println("-0.75-> current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(1.0); > + System.out.println("<-1.0-- current="+a.currentValue()); > + } > + } > + System.out.println("--- negative wrap test ---"); > + a=new DecayingKeyspaceAverage(0.2, 10, null); > + a.report(0.2); > + for (int wrap=3; wrap!=0; wrap--) { > + System.out.println("negwrap test #"+wrap); > + for (int i=10; i!=0; i--) { > + a.report(0.75); > + System.out.println("-0.75-> current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(0.5); > + System.out.println("<-0.5-- current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(0.25); > + System.out.println("<-0.25- current="+a.currentValue()); > + } > + for (int i=10; i!=0; i--) { > + a.report(1.0); > + System.out.println("--1.0-> current="+a.currentValue()); > + } > + } > + } > +} > \ No newline at end of file > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/ff68ba22/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 15:11:36 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 15:11:36 +0000 Subject: [freenet-dev] [freenet-cvs] r16826 - trunk/freenet/src/freenet/node In-Reply-To: <20071228165118.B96914798DD@freenetproject.org> References: <20071228165118.B96914798DD@freenetproject.org> Message-ID: <200801031511.36969.toad@amphibian.dyndns.org> Isn't sendSync() a longer timeout than the waitFor()? We could change that though, pass in a timeout..? On Friday 28 December 2007 16:51, robert at freenetproject.org wrote: > Author: robert > Date: 2007-12-28 16:51:18 +0000 (Fri, 28 Dec 2007) > New Revision: 16826 > > Modified: > trunk/freenet/src/freenet/node/InsertHandler.java > Log: > less timeouts which are really disconnects > > > Modified: trunk/freenet/src/freenet/node/InsertHandler.java > =================================================================== > --- trunk/freenet/src/freenet/node/InsertHandler.java 2007-12-28 16:50:28 UTC (rev 16825) > +++ trunk/freenet/src/freenet/node/InsertHandler.java 2007-12-28 16:51:18 UTC (rev 16826) > @@ -91,7 +91,8 @@ > // Send Accepted > Message accepted = DMT.createFNPAccepted(uid); > try { > - source.sendAsync(accepted, null, 0, this); > + //Using sendSync here will help the next message filter not timeout... wait here or at the message filter. > + source.sendSync(accepted, this); > } catch (NotConnectedException e1) { > if(logMINOR) Logger.minor(this, "Lost connection to source"); > return; > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/2f615c5d/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 15:19:47 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 15:19:47 +0000 Subject: [freenet-dev] [freenet-cvs] r16833 - trunk/freenet/src/freenet/node In-Reply-To: <20071229014106.A62284796F8@freenetproject.org> References: <20071229014106.A62284796F8@freenetproject.org> Message-ID: <200801031519.48197.toad@amphibian.dyndns.org> On Saturday 29 December 2007 01:41, robert at freenetproject.org wrote: > Author: robert > Date: 2007-12-29 01:41:06 +0000 (Sat, 29 Dec 2007) > New Revision: 16833 > > Modified: > trunk/freenet/src/freenet/node/PeerNode.java > Log: > maybe help wont-fetch-ark deadlock > > > Modified: trunk/freenet/src/freenet/node/PeerNode.java > =================================================================== > --- trunk/freenet/src/freenet/node/PeerNode.java 2007-12-29 01:37:31 UTC (rev 16832) > +++ trunk/freenet/src/freenet/node/PeerNode.java 2007-12-29 01:41:06 UTC (rev 16833) > @@ -348,7 +348,7 @@ > disableRoutingHasBeenSetRemotely = false; // Assume so > > lastGoodVersion = fs.get("lastGoodVersion"); > - updateShouldDisconnectNow(); > + //updateShouldDisconnectNow(); > > testnetEnabled = fs.getBoolean("testnet", false); > if(node.testnetEnabled != testnetEnabled) { > @@ -2781,8 +2781,11 @@ > } > > synchronized void updateShouldDisconnectNow() { > - verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > - verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > + //FIXME: We should not update VERIFIED unless we HANDSHAKE WITH THE NODE > + if (isConnected()) { > + verifiedIncompatibleOlderVersion = forwardInvalidVersion(); > + verifiedIncompatibleNewerVersion = reverseInvalidVersion(); > + } > } Please restore the original version. It looks like it was correct after all, and the problem is not fetching ARKs when verified*=true. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/cec91a45/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 15:23:14 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 15:23:14 +0000 Subject: [freenet-dev] [freenet-cvs] r16837 - trunk/freenet/src/freenet/node In-Reply-To: <20071229023617.0779F47B7A2@freenetproject.org> References: <20071229023617.0779F47B7A2@freenetproject.org> Message-ID: <200801031523.14611.toad@amphibian.dyndns.org> On Saturday 29 December 2007 02:36, robert at freenetproject.org wrote: > Author: robert > Date: 2007-12-29 02:36:16 +0000 (Sat, 29 Dec 2007) > New Revision: 16837 > > Modified: > trunk/freenet/src/freenet/node/FNPPacketMangler.java > Log: > opps, no... 'changeIP' is while connected, 'auth' is while disconnected (partially reverts r16836) It's possible in both cases afaics. So both commits should be reverted. No? > > Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java > =================================================================== > --- trunk/freenet/src/freenet/node/FNPPacketMangler.java 2007-12-29 02:12:19 UTC (rev 16836) > +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java 2007-12-29 02:36:16 UTC (rev 16837) > @@ -237,7 +237,7 @@ > for(int i=0;i pn = peers[i]; > if(pn == opn) continue; > - if(pn.isConnected()) continue; > + if(!pn.isConnected()) continue; > if(tryProcess(buf, offset, length, pn.getCurrentKeyTracker(), now)) { > // IP address change > pn.changedIP(peer); > @@ -261,6 +261,7 @@ > for(int i=0;i pn = peers[i]; > if(pn == opn) continue; > + if(pn.isConnected()) continue; > if(tryProcessAuth(buf, offset, length, pn, peer,false, now)) return; > } > } > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/5f387ceb/attachment.pgp From toad at amphibian.dyndns.org Thu Jan 3 15:25:55 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 15:25:55 +0000 Subject: [freenet-dev] [freenet-cvs] r16839 - trunk/freenet/src/freenet/node In-Reply-To: <20071229133433.A1D8447BBE8@freenetproject.org> References: <20071229133433.A1D8447BBE8@freenetproject.org> Message-ID: <200801031525.56456.toad@amphibian.dyndns.org> On Saturday 29 December 2007 13:34, nextgens at freenetproject.org wrote: > Author: nextgens > Date: 2007-12-29 13:34:33 +0000 (Sat, 29 Dec 2007) > New Revision: 16839 > > Modified: > trunk/freenet/src/freenet/node/FNPPacketMangler.java > Log: > jfk: Fix the issue spotted by robert (see http://archives.freenetproject.org/message/20071229.105331.b1a491f0.en.html) > > That might solve the "I've lost the exponential" problem It might? Wouldn't the old code cause an NPE? > > Modified: trunk/freenet/src/freenet/node/FNPPacketMangler.java > =================================================================== > --- trunk/freenet/src/freenet/node/FNPPacketMangler.java 2007-12-29 09:36:50 UTC (rev 16838) > +++ trunk/freenet/src/freenet/node/FNPPacketMangler.java 2007-12-29 13:34:33 UTC (rev 16839) > @@ -2640,8 +2640,8 @@ > return result; > } > } > - //FIXME: Isn't this wrong? 'result.myExponential' should be exponential? And what if dhContextToBePrunned is null? > - if((dhContextToBePrunned.myExponential).equals(result.myExponential)) > + > + if((dhContextToBePrunned != null) && ((dhContextToBePrunned.myExponential).equals(exponential))) > return dhContextToBePrunned; > } > return null; > > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/cvs > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/5a926a5b/attachment.pgp From robert at emu.freenetproject.org Thu Jan 3 15:35:39 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Thu, 3 Jan 2008 09:35:39 -0600 Subject: [freenet-dev] [freenet-cvs] r16837 - trunk/freenet/src/freenet/node In-Reply-To: <200801031523.14611.toad@amphibian.dyndns.org> References: <20071229023617.0779F47B7A2@freenetproject.org> <200801031523.14611.toad@amphibian.dyndns.org> Message-ID: <29CC96D5-5368-43CF-8273-33BF6BEB0136@emu.freenetproject.org> On Jan 3, 2008, at 9:23 AM, Matthew Toseland wrote: > On Saturday 29 December 2007 02:36, robert at freenetproject.org wrote: >> Author: robert >> Date: 2007-12-29 02:36:16 +0000 (Sat, 29 Dec 2007) >> New Revision: 16837 >> >> Modified: >> trunk/freenet/src/freenet/node/FNPPacketMangler.java >> Log: >> opps, no... 'changeIP' is while connected, 'auth' is while >> disconnected > (partially reverts r16836) > > It's possible in both cases afaics. So both commits should be > reverted. No? Reverted in r16843 at nextgens request. -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emu.freenetproject.org/pipermail/devl/attachments/20080103/e96fe279/attachment.htm From nextgens at freenetproject.org Thu Jan 3 15:56:47 2008 From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=) Date: Thu, 3 Jan 2008 16:56:47 +0100 Subject: [freenet-dev] [freenet-cvs] r16839 - trunk/freenet/src/freenet/node In-Reply-To: <200801031525.56456.toad@amphibian.dyndns.org> References: <20071229133433.A1D8447BBE8@freenetproject.org> <200801031525.56456.toad@amphibian.dyndns.org> Message-ID: <20080103155647.GE4339@freenetproject.org> * Matthew Toseland [2008-01-03 15:25:55]: > On Saturday 29 December 2007 13:34, nextgens at freenetproject.org wrote: > > Author: nextgens > > Date: 2007-12-29 13:34:33 +0000 (Sat, 29 Dec 2007) > > New Revision: 16839 > > > > Modified: > > trunk/freenet/src/freenet/node/FNPPacketMangler.java > > Log: > > jfk: Fix the issue spotted by robert (see > http://archives.freenetproject.org/message/20071229.105331.b1a491f0.en.html) > > > > That might solve the "I've lost the exponential" problem > > It might? Wouldn't the old code cause an NPE? Well that's a fix-of-a-fix-of-a-fix, so yes, I won't dare saying it will fix it. No it wouldn't cause an npe... because of the way we instanciate the class... but it's a good practice to check for null there. If it was causing NPEs we would have spotted it earlier ;) NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080103/ff62597d/attachment.pgp From robert at emu.freenetproject.org Thu Jan 3 16:12:56 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Thu, 3 Jan 2008 10:12:56 -0600 Subject: [freenet-dev] [freenet-cvs] r16817 - in trunk/freenet/src/freenet: node support/math In-Reply-To: <200801031503.34926.toad@amphibian.dyndns.org> References: <20071226205138.AA33B47A371@freenetproject.org> <200801031503.34926.toad@amphibian.dyndns.org> Message-ID: On Jan 3, 2008, at 9:03 AM, Matthew Toseland wrote: > Useful class, but I'm really not convinced it's statistically sound. > You need > to normalize the stored value after every operation, otherwise as it > gets > larger, you will get bigger jumps when values are reported. In order > to do > this, you probably need to extend BDRA; put some hooks in. Hmmm... yes, in review you are right, as averaging is not linear as such: assume: avg(a, b, c... x, y) = z then: avg(a+1, b+1, c+1... x+1, y+1) != z+1 An implementation using normalized stored values is possible by adding a single package-hook: setCurrentValue(double d); Then, in the averager, on report() to call avg.setCurrentValue(Location.normalize(avg.currentValue()); Implemented in r16855. -- Robert Hailey > On Wednesday 26 December 2007 20:51, robert at freenetproject.org wrote: >> Author: robert >> Date: 2007-12-26 20:51:38 +0000 (Wed, 26 Dec 2007) >> New Revision: 16817 >> >> Added: >> trunk/freenet/src/freenet/support/math/DecayingKeyspaceAverage.java >> Modified: >> trunk/freenet/src/freenet/node/Location.java >> trunk/freenet/src/freenet/node/NodeStats.java >> Log: >> implement keyspace-aware averager -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emu.freenetproject.org/pipermail/devl/attachments/20080103/1067c949/attachment.htm From robert at emu.freenetproject.org Thu Jan 3 16:29:32 2008 From: robert at emu.freenetproject.org (Robert Hailey) Date: Thu, 3 Jan 2008 10:29:32 -0600 Subject: [freenet-dev] [freenet-cvs] r16833 - trunk/freenet/src/freenet/node In-Reply-To: <200801031519.48197.toad@amphibian.dyndns.org> References: <20071229014106.A62284796F8@freenetproject.org> <200801031519.48197.toad@amphibian.dyndns.org> Message-ID: On Jan 2, 2008, at 7:38 AM, Florent Daigni?re wrote: >> Why not just use if(isConnected()) { ... } ? As far as I can see >> that is >> correct: if we're not connected, we don't care about verified*. > > You're suggesting to revert robert's patch, wich is fine by me... as I > said, I don't understand why it helps > > NextGen$ On Jan 3, 2008, at 9:19 AM, Matthew Toseland wrote: > Please restore the original version. It looks like it was correct > after all, > and the problem is not fetching ARKs when verified*=true. If you really want me to, I certainly will, but... if you and nextgens agree that it is benign to active connections, and in my reasoning prevents a deadlock for long disconnections... why? I think that it would be more useful to simply rename the identifiers to be more intuitive until the ark problem is solved to your satisfaction (e.g. as David said he may). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://emu.freenetproject.org/pipermail/devl/attachments/20080103/a3bc7665/attachment.htm From toad at amphibian.dyndns.org Thu Jan 3 16:30:36 2008 From: toad at amphibian.dyndns.org (Matthew Toseland) Date: Thu, 3 Jan 2008 16:30:36 +0000 Subject: [freenet-dev] [freenet-cvs] Verification of r16847 on emu In-Reply-To: <20080102165044.31E5C47BC01@freenetproject.org> References: <20080102165044.31E5C47BC01@freenetproject.org> Message-ID: <200801031630.42241.toad@amphibian.dyndns.org> Doh. Well it's technically a trivial refactoring; read the commit! On Wednesday 02 January 2008 16:50, svn-build at freenetproject.org wrote: > toad has declared that 16847 is an 'indent only' commit: > That's FALSE. > > Files orig/FileLoggerHook$WriterThread.class and new/FileLoggerHook$WriterThread.class differ > orig/FileLoggerHook$1.class : ec2113c9326737fecf85a3fde2029b6320496215 : ec2113c9326737fecf85a3fde2029b6320496215 > orig/FileLoggerHook.class : eefd01f8fc2283859e8abd8217d8a96eae2381d2 : eefd01f8fc2283859e8abd8217d8a96eae2381d2 > orig/FileLoggerHook$CloserThread.class : 0ea1a612efe4f3448e8b1d7385e33f2155298d34 : 0ea1a612efe4f3448e8b1d7385e33f2155298d34 > orig/FileLoggerHook$IntervalParseException.class : 5275ef6554ff1a86082cff5123c2cd2866737e41 : 5275ef6554ff1a86082cff5123c2cd2866737e41 > orig/FileLoggerHook$OldLogFile.class : 7cae6bc6c59831a86fd27596f411be688516a486 : 7cae6bc6c59831a86fd27596f411be688516a486 > orig/FileLoggerHook$WriterThread.class : dd82d2a08c1a0234400bccd04eaefbbfb0eaaa3e : 448c28f732b0a6804af921d7a4a0d3f05cc0b580 > _______________________________________________ > cvs mailing list > cvs at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailma