From luke771 at gmail.com  Tue May  1 09:52:13 2007
From: luke771 at gmail.com (Luke771)
Date: Tue, 01 May 2007 11:52:13 +0200
Subject: [freenet-dev] it. transl. v.10 ph00
Message-ID: <46370DCD.2090301@gmail.com>

-Fixed a bunch of typos and mistakes
-Rephrased some strings
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v10
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070501/b7e68c92/attachment.txt 

From rah at bash.sh  Tue May  1 16:28:05 2007
From: rah at bash.sh (Bob Ham)
Date: Tue, 01 May 2007 17:28:05 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
Message-ID: <1178036885.25584.0.camel@orchid.arb.net>

On Mon, 2007-04-30 at 18:19 +0200, bbackde at googlemail.com wrote:

> I've noticed this as well on downloads.  If I change the priority,
> either lower or higher, the download will start retrieving blocks
> again.

I can confirm this behaviour.

-- 
Bob Ham <rah at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070501/6027e2d2/attachment.pgp 

From nextgens at freenetproject.org  Tue May  1 16:46:12 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Tue, 1 May 2007 18:46:12 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <1178036885.25584.0.camel@orchid.arb.net>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
Message-ID: <20070501164611.GF5938@freenetproject.org>

* Bob Ham <rah at bash.sh> [2007-05-01 17:28:05]:

> On Mon, 2007-04-30 at 18:19 +0200, bbackde at googlemail.com wrote:
> 
> > I've noticed this as well on downloads.  If I change the priority,
> > either lower or higher, the download will start retrieving blocks
> > again.
> 
> I can confirm this behaviour.

changing the priority of a request calls
ClientRequestScheduler.reregisterAll(ClientRequester) ... meaning that
nothing is very surprising...

NextGen$
PS: see
https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/client/async/ClientRequestScheduler.java
-------------- 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/20070501/6cf4bfeb/attachment.pgp 

From bbackde at googlemail.com  Tue May  1 16:50:31 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Tue, 1 May 2007 18:50:31 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070501164611.GF5938@freenetproject.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
Message-ID: <d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>

You may be right. But the problem is that the request seem to stall
internally without to fail or to do anything else. And this is not ok.

So now we know that reregisterAll helps, nothing new but its an info :)

Some solution would be nice. Toad siad this is hard to debug, but if
we check the various user reports then many users seem to have this
problem.

On 5/1/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * Bob Ham <rah at bash.sh> [2007-05-01 17:28:05]:
>
> > On Mon, 2007-04-30 at 18:19 +0200, bbackde at googlemail.com wrote:
> >
> > > I've noticed this as well on downloads.  If I change the priority,
> > > either lower or higher, the download will start retrieving blocks
> > > again.
> >
> > I can confirm this behaviour.
>
> changing the priority of a request calls
> ClientRequestScheduler.reregisterAll(ClientRequester) ... meaning that
> nothing is very surprising...
>
> NextGen$
> PS: see
> https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/client/async/ClientRequestScheduler.java
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGN27SU/Z/dHFfxtcRAmDfAKCsQIEul7CNwaVWpp/qKMSQNFbblQCffsuJ
> Tsf9Usaoh1McV42g5gELxN0=
> =cZnG
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From nextgens at freenetproject.org  Tue May  1 17:02:33 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Tue, 1 May 2007 19:02:33 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
Message-ID: <20070501170233.GG5938@freenetproject.org>

* bbackde at googlemail.com <bbackde at googlemail.com> [2007-05-01 18:50:31]:

> You may be right. But the problem is that the request seem to stall
> internally without to fail or to do anything else. And this is not ok.
> 

Agreed.

> So now we know that reregisterAll helps, nothing new but its an info :)
> 

It's worthless; getting new blocks doesn't mean you got blocks you were
requesting before you rescheduled the task... It could be new ones.

> Some solution would be nice.

Any bugfix is always nice to have :)

> Toad siad this is hard to debug, but if we check the various user reports
> then many users seem to have this problem.
> 

I do think that it is hard to debug as well... and I don't think that
user reports can help us with that matter :| by replying I was willing
to acknowledge the fact that it's a known bug and that changing the
priority is likely to speed things up; That doesn't mean I know how to
fix the root cause of the problem.

We need to catch the bug; implementing a hack (like starting more requests,
rescheduling everything on a regular basis, implementing some stateful
tracking of started requests) would only be a workaround.

> On 5/1/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> >* Bob Ham <rah at bash.sh> [2007-05-01 17:28:05]:
> >
> >> On Mon, 2007-04-30 at 18:19 +0200, bbackde at googlemail.com wrote:
> >>
> >> > I've noticed this as well on downloads.  If I change the priority,
> >> > either lower or higher, the download will start retrieving blocks
> >> > again.
> >>
> >> I can confirm this behaviour.
> >
> >changing the priority of a request calls
> >ClientRequestScheduler.reregisterAll(ClientRequester) ... meaning that
> >nothing is very surprising...
> >
> >NextGen$
> >PS: see
> >https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/client/async/ClientRequestScheduler.java
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.6 (GNU/Linux)
> >
> >iD8DBQFGN27SU/Z/dHFfxtcRAmDfAKCsQIEul7CNwaVWpp/qKMSQNFbblQCffsuJ
> >Tsf9Usaoh1McV42g5gELxN0=
> >=cZnG
> >-----END PGP SIGNATURE-----
> >
> >_______________________________________________
> >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: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070501/23a54cbb/attachment.pgp 

From bbackde at googlemail.com  Tue May  1 17:08:13 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Tue, 1 May 2007 19:08:13 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070501170233.GG5938@freenetproject.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
	<20070501170233.GG5938@freenetproject.org>
Message-ID: <d6149a790705011008m645ba441j25026392d3c3ee2a@mail.gmail.com>

Ok nice. And I didn't want to offend you, I just wanted to get this
problem back in mind :)

Thanks.

On 5/1/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-05-01 18:50:31]:
>
> > You may be right. But the problem is that the request seem to stall
> > internally without to fail or to do anything else. And this is not ok.
> >
>
> Agreed.
>
> > So now we know that reregisterAll helps, nothing new but its an info :)
> >
>
> It's worthless; getting new blocks doesn't mean you got blocks you were
> requesting before you rescheduled the task... It could be new ones.
>
> > Some solution would be nice.
>
> Any bugfix is always nice to have :)
>
> > Toad siad this is hard to debug, but if we check the various user reports
> > then many users seem to have this problem.
> >
>
> I do think that it is hard to debug as well... and I don't think that
> user reports can help us with that matter :| by replying I was willing
> to acknowledge the fact that it's a known bug and that changing the
> priority is likely to speed things up; That doesn't mean I know how to
> fix the root cause of the problem.
>
> We need to catch the bug; implementing a hack (like starting more requests,
> rescheduling everything on a regular basis, implementing some stateful
> tracking of started requests) would only be a workaround.
>
> > On 5/1/07, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote:
> > >* Bob Ham <rah at bash.sh> [2007-05-01 17:28:05]:
> > >
> > >> On Mon, 2007-04-30 at 18:19 +0200, bbackde at googlemail.com wrote:
> > >>
> > >> > I've noticed this as well on downloads.  If I change the priority,
> > >> > either lower or higher, the download will start retrieving blocks
> > >> > again.
> > >>
> > >> I can confirm this behaviour.
> > >
> > >changing the priority of a request calls
> > >ClientRequestScheduler.reregisterAll(ClientRequester) ... meaning that
> > >nothing is very surprising...
> > >
> > >NextGen$
> > >PS: see
> > >https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/client/async/ClientRequestScheduler.java
> > >
> > >-----BEGIN PGP SIGNATURE-----
> > >Version: GnuPG v1.4.6 (GNU/Linux)
> > >
> > >iD8DBQFGN27SU/Z/dHFfxtcRAmDfAKCsQIEul7CNwaVWpp/qKMSQNFbblQCffsuJ
> > >Tsf9Usaoh1McV42g5gELxN0=
> > >=cZnG
> > >-----END PGP SIGNATURE-----
> > >
> > >_______________________________________________
> > >Devl mailing list
> > >Devl at freenetproject.org
> > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> > >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGN3KpU/Z/dHFfxtcRAo74AJ4i2vUl8sSRjJcAhDRZDxYGfUhmAgCcDXJJ
> 0Q9GuJgO4X9uW88UzJArjSE=
> =In3v
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From rah at bash.sh  Wed May  2 13:33:13 2007
From: rah at bash.sh (Bob Ham)
Date: Wed, 02 May 2007 14:33:13 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070501170233.GG5938@freenetproject.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
	<20070501170233.GG5938@freenetproject.org>
Message-ID: <1178112793.8707.1.camel@localhost>

On Tue, 2007-05-01 at 19:02 +0200, Florent Daigni?re (NextGen$) wrote:
> * bbackde at googlemail.com <bbackde at googlemail.com> [2007-05-01 18:50:31]:

> > So now we know that reregisterAll helps, nothing new but its an info :)
> > 
> 
> It's worthless

No it isn't.

> We need to catch the bug; implementing a hack ... would only be a workaround.

Perhaps implement something to help catch the bug?

Bob

-- 
Bob Ham <rah at bash.sh>


From nextgens at freenetproject.org  Wed May  2 13:35:59 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Wed, 2 May 2007 15:35:59 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <1178112793.8707.1.camel@localhost>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
	<20070501170233.GG5938@freenetproject.org>
	<1178112793.8707.1.camel@localhost>
Message-ID: <20070502133559.GE5564@freenetproject.org>

* Bob Ham <rah at bash.sh> [2007-05-02 14:33:13]:

> On Tue, 2007-05-01 at 19:02 +0200, Florent Daigni?re (NextGen$) wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-05-01 18:50:31]:
> 
> > > So now we know that reregisterAll helps, nothing new but its an info :)
> > > 
> > 
> > It's worthless
> 
> No it isn't.
> 
> > We need to catch the bug; implementing a hack ... would only be a workaround.
> 
> Perhaps implement something to help catch the bug?
> 
> Bob

Go ahead! where is the patch ?

We already have plenty of logging messages.

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/20070502/9f7049ec/attachment.pgp 

From rah at bash.sh  Wed May  2 13:49:37 2007
From: rah at bash.sh (Bob Ham)
Date: Wed, 02 May 2007 14:49:37 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070502133559.GE5564@freenetproject.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
	<20070501170233.GG5938@freenetproject.org>
	<1178112793.8707.1.camel@localhost>
	<20070502133559.GE5564@freenetproject.org>
Message-ID: <1178113779.8707.6.camel@localhost>

On Wed, 2007-05-02 at 15:35 +0200, Florent Daigni?re (NextGen$) wrote:
> * Bob Ham <rah at bash.sh> [2007-05-02 14:33:13]:
> > 
> > > We need to catch the bug; implementing a hack ... would only be a workaround.
> > 
> > Perhaps implement something to help catch the bug?

> Go ahead! where is the patch ?

I don't know.  Ask the "we" you said needed to catch the bug.

Bob

-- 
Bob Ham <rah at bash.sh>


From nextgens at freenetproject.org  Wed May  2 14:12:20 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re_=28NextGen$=29?=)
Date: Wed, 2 May 2007 16:12:20 +0200
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <1178112793.8707.1.camel@localhost>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
	<20070501170233.GG5938@freenetproject.org>
	<1178112793.8707.1.camel@localhost>
Message-ID: <20070502141219.GF5564@freenetproject.org>

* Bob Ham <rah at bash.sh> [2007-05-02 14:33:13]:

> On Tue, 2007-05-01 at 19:02 +0200, Florent Daigni?re (NextGen$) wrote:
> > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-05-01 18:50:31]:
> 
> > > So now we know that reregisterAll helps, nothing new but its an info :)
> > > 
> > 
> > It's worthless
> 
> No it isn't.
> 

Well, you obviously have some knowledge I lack, may you use your insight and
expain to me what is worthy then ?

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/20070502/76174ee1/attachment.pgp 

From toad at amphibian.dyndns.org  Wed May  2 14:25:26 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 2 May 2007 15:25:26 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <4633EE54.6070802@cs.ucl.ac.uk>
References: <5172132.1177437285862.JavaMail.root@web34>
	<4633EE54.6070802@cs.ucl.ac.uk>
Message-ID: <20070502142526.GD23783@amphibian.dyndns.org>

On Sun, Apr 29, 2007 at 02:01:08AM +0100, Michael Rogers wrote:
> jdaviestx wrote:
> > The problem is, people have been building their small-world connections for, what, two years now?  The darknet hasn't made it over to me yet...
> 
> This is definitely one of the downsides of the darknet approach in
> general. But it's exacerbated by the fact that Freenet is trying to
> build one global network, as opposed to, say, WASTE, where there are
> lots of small, separate networks. It's probably easier to find three
> friends who want to set up a small network than it is to find three
> friends who already belong to the big network, and that's likely to
> remain true until the big network becomes ubiquitous. Of course we don't
> want to stay in small, isolated networks forever; ideally we'd set up
> small networks with our friends and merge them into the big network
> later, but unfortunately I don't think Freenet's architecture can
> accommodate that.

Why not? Because small, isolated networks are useless?
> 
> Cheers,
> Michael
-------------- 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/20070502/c9319090/attachment.pgp 

From rah at bash.sh  Wed May  2 14:35:06 2007
From: rah at bash.sh (Bob Ham)
Date: Wed, 02 May 2007 15:35:06 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070502141219.GF5564@freenetproject.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<1178036885.25584.0.camel@orchid.arb.net>
	<20070501164611.GF5938@freenetproject.org>
	<d6149a790705010950k99a0afbue1cedd34988a6ff2@mail.gmail.com>
	<20070501170233.GG5938@freenetproject.org>
	<1178112793.8707.1.camel@localhost>
	<20070502141219.GF5564@freenetproject.org>
Message-ID: <1178116506.8707.10.camel@localhost>

On Wed, 2007-05-02 at 16:12 +0200, Florent Daigni?re (NextGen$) wrote:
> * Bob Ham <rah at bash.sh> [2007-05-02 14:33:13]:
> 
> > On Tue, 2007-05-01 at 19:02 +0200, Florent Daigni?re (NextGen$) wrote:
> > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-05-01 18:50:31]:
> > 
> > > > So now we know that reregisterAll helps, nothing new but its an info :)
> > > > 
> > > 
> > > It's worthless
> > 
> > No it isn't.
> > 
> 
> Well, you obviously have some knowledge I lack, may you use your insight and
> expain to me what is worthy then ?

I don't have some knowledge you lack, I simply have a different opinion
on what is worthless.

Bob

-- 
Bob Ham <rah at bash.sh>


From jdaviestx at tx.rr.com  Wed May  2 18:21:17 2007
From: jdaviestx at tx.rr.com (jdaviestx at tx.rr.com)
Date: Wed, 2 May 2007 11:21:17 -0700
Subject: [freenet-dev] Story Submitted to Slashdot
Message-ID: <10498389.1178130077986.JavaMail.root@web24>


---- Matthew Toseland <toad at amphibian.dyndns.org> wrote: 
> On Sun, Apr 29, 2007 at 02:01:08AM +0100, Michael Rogers wrote:
> > lots of small, separate networks. It's probably easier to find three
> > friends who want to set up a small network than it is to find three
> 
> Why not? Because small, isolated networks are useless?

I'm curious - for those of you who have had success with the Darknet approach, how did you approach your peers?  Did you happen to know in person three people who frequent this mailing list, or did you e-mail a link to the freenet home page to a few friends and say "are you interested?"

Once you did... what was on your network?  Were you all pulling things off of Usenet and WWW or ripping CD tracks and injecting them into your personal network?  Did you find it worthwhile?

I'm not sure that I'd go so far as to say that small, isolated networks are _useless_ per se, but when it's a "totally anonymous" network of just three or four people...  Do any of you know (or have some sort of guesstimate) as to how big your small, isolated network became (or currently is)?


From toad at amphibian.dyndns.org  Wed May  2 23:43:35 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 00:43:35 +0100
Subject: [freenet-dev] Freenet 0.7 build 1031
Message-ID: <20070502234335.GA9388@amphibian.dyndns.org>

Freenet 0.7 build 1031 is now available. Please upgrade. This build
fixes a major bug which was causing downloads to hang. Also a few other
bugfixes, and some work on localisation. Most of the fproxy frontend is
now translateable; thanks to _ph00 and Cooo we actually have
translations (into Italian and Swedish) for a lot of it.

Please upgrade, and tell us if the auto-update fails, or if you find any
bugs. Thank you for using Freenet!
-------------- 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/20070503/74373874/attachment.pgp 

From toad at amphibian.dyndns.org  Wed May  2 23:46:24 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 00:46:24 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
Message-ID: <20070502234624.GA13346@amphibian.dyndns.org>

1031 should fix this bug. Please try it.

On Mon, Apr 30, 2007 at 06:19:10PM +0200, bbackde at googlemail.com wrote:
> This seems to be related to the problem, maybe you get an idea what wents wrong:
> 
> ----- Underworld at TKeLmt1AnnTXyPZReBJzxFzbceg ----- 2007.04.29 -
> 20:34:36GMT -----
> 
> FYI -
> If a FQUID download stalls, try lowering the priority, and then
> raising it again. This seems to get things moving. I had been using
> "Retry Failed Blocks" but this actually restarts the download from
> scratch.
> I don't know why this works, but it does.
> You can also do the same thing from the FProxy Queue Page. So the
> stalling is a really a Freenet issue and not a problem with FQUID.
> 
> ----- Anonymous ----- 2007.04.29 - 21:08:44GMT -----
> 
> I've noticed this as well on downloads.  If I change the priority,
> either lower or higher, the download will start retrieving blocks
> again.
> 
> 
> On 4/25/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > On Tue, Apr 24, 2007 at 06:27:22PM +0200, bbackde at googlemail.com wrote:
> > > Just an obervation: I have a download running which stucks at some
> > > point. But it keeps running, means it doesn't fail. No matter how long
> > > the node runs, the download seems to hang. If I restart the node, then
> > > suddenly the download continues and more blocks arrive, until it
> > > stucks again. If I restart the node each time when the download
> > > stucks, then it completes sometimes.
> > >
> > > Could this be an internal problem?
> >
> > Quite possibly. We've had such reports from time to time, but it is very
> > difficult to reproduce so it can't be debugged. :(
-------------- 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/20070503/9d9067a8/attachment.pgp 

From rah at bash.sh  Thu May  3 06:31:53 2007
From: rah at bash.sh (Bob Ham)
Date: Thu, 03 May 2007 07:31:53 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070502234624.GA13346@amphibian.dyndns.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<20070502234624.GA13346@amphibian.dyndns.org>
Message-ID: <1178173913.25006.2.camel@orchid.arb.net>

On Thu, 2007-05-03 at 00:46 +0100, Matthew Toseland wrote:
> 1031 should fix this bug. Please try it.

What was the problem?

Bob

-- 
Bob Ham <rah at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070503/db10aa3a/attachment.pgp 

From toad at amphibian.dyndns.org  Thu May  3 10:22:35 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 11:22:35 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <1178173913.25006.2.camel@orchid.arb.net>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<20070502234624.GA13346@amphibian.dyndns.org>
	<1178173913.25006.2.camel@orchid.arb.net>
Message-ID: <20070503102235.GB24370@amphibian.dyndns.org>

On Thu, May 03, 2007 at 07:31:53AM +0100, Bob Ham wrote:
> On Thu, 2007-05-03 at 00:46 +0100, Matthew Toseland wrote:
> > 1031 should fix this bug. Please try it.
> 
> What was the problem?

A bug in the request queue code that only happens on downloads because
only on downloads can a segment be cancelled (because it is decoding, or decoded)
while the overall file is not cancelled.
> 
> Bob
-------------- 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/20070503/38736472/attachment.pgp 

From rah at bash.sh  Thu May  3 10:54:49 2007
From: rah at bash.sh (Bob Ham)
Date: Thu, 03 May 2007 11:54:49 +0100
Subject: [freenet-dev] Persistent downloads never internally restarted?
In-Reply-To: <20070503102235.GB24370@amphibian.dyndns.org>
References: <d6149a790704240927m10b8561ck44f0537ee707f5ba@mail.gmail.com>
	<20070425155027.GA11213@amphibian.dyndns.org>
	<d6149a790704300919l4911f2d7l4a10d762b389555a@mail.gmail.com>
	<20070502234624.GA13346@amphibian.dyndns.org>
	<1178173913.25006.2.camel@orchid.arb.net>
	<20070503102235.GB24370@amphibian.dyndns.org>
Message-ID: <1178189690.10595.1.camel@localhost>

On Thu, 2007-05-03 at 11:22 +0100, Matthew Toseland wrote:
> On Thu, May 03, 2007 at 07:31:53AM +0100, Bob Ham wrote:
> > On Thu, 2007-05-03 at 00:46 +0100, Matthew Toseland wrote:
> > > 1031 should fix this bug. Please try it.
> > 
> > What was the problem?
> 
> A bug in the request queue code that only happens on downloads because
> only on downloads can a segment be cancelled (because it is decoding, or decoded)
> while the overall file is not cancelled.

Interesting.  What I meant, though, was what was the problem? :-)  Under
what circumstances would a download freeze?

Bob

-- 
Bob Ham <rah at bash.sh>


From m.rogers at cs.ucl.ac.uk  Thu May  3 12:40:15 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Thu, 03 May 2007 13:40:15 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070502142526.GD23783@amphibian.dyndns.org>
References: <5172132.1177437285862.JavaMail.root@web34>
	<4633EE54.6070802@cs.ucl.ac.uk>
	<20070502142526.GD23783@amphibian.dyndns.org>
Message-ID: <4639D82F.5040709@cs.ucl.ac.uk>

Matthew Toseland wrote:
>> Of course we don't
>> want to stay in small, isolated networks forever; ideally we'd set up
>> small networks with our friends and merge them into the big network
>> later, but unfortunately I don't think Freenet's architecture can
>> accommodate that.
> 
> Why not? Because small, isolated networks are useless?

That's a pretty strong statement - are you talking about isolated
Freenet networks or isolated networks in general? Because there are a
lot of people using Direct Connect (not to mention private IRC channels,
FTP servers, etc etc).

Clearly the "one big network" approach and the "many small networks"
approach both have their advantages. For example, you have no anonymity
on a small network. On the other hand it's easier to find people to peer
with - if you don't know any members of the big network, just start your
own network with a couple of friends.

All I'm trying to say is that in an ideal world we'd get the advantages
of both approaches if people could set up their own small networks and
later merge them into the big network.

Cheers,
Michael


From m.rogers at cs.ucl.ac.uk  Thu May  3 12:43:46 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Thu, 03 May 2007 13:43:46 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <10498389.1178130077986.JavaMail.root@web24>
References: <10498389.1178130077986.JavaMail.root@web24>
Message-ID: <4639D902.5020604@cs.ucl.ac.uk>

jdaviestx wrote:
> I'm curious - for those of you who have had success with the Darknet approach, how did you approach your peers?  Did you happen to know in person three people who frequent this mailing list, or did you e-mail a link to the freenet home page to a few friends and say "are you interested?"
> 
> Once you did... what was on your network?  Were you all pulling things off of Usenet and WWW or ripping CD tracks and injecting them into your personal network?  Did you find it worthwhile?

Sorry if I'm misunderstanding, but are you suggesting that people have
already set up private Freenet networks? That's not something that had
occured to me. Wouldn't we get horrible b0rkage if somebody accidentally
bridged two networks? Maybe if people are really setting up private
networks we should introduce some kind of network name (like WASTE has)
to prevent accidental bridging?

Cheers,
Michael


From jdaviestx at tx.rr.com  Thu May  3 13:29:33 2007
From: jdaviestx at tx.rr.com (jdaviestx at tx.rr.com)
Date: Thu, 3 May 2007 6:29:33 -0700
Subject: [freenet-dev] Story Submitted to Slashdot
Message-ID: <16635578.1178198973468.JavaMail.root@web36>


---- Michael Rogers <m.rogers at cs.ucl.ac.uk> wrote: 
> Sorry if I'm misunderstanding, but are you suggesting that people have
> already set up private Freenet networks? That's not something that had
> occured to me. Wouldn't we get horrible b0rkage if somebody accidentally
> bridged two networks? Maybe if people are really setting up private
> networks we should introduce some kind of network name (like WASTE has)
> to prevent accidental bridging?

Isn't that the point of the darknet?  Everybody sets up small networks, and then connects the small networks to other small networks to create bigger networks until there's just one big network?


From rah at bash.sh  Thu May  3 14:29:45 2007
From: rah at bash.sh (Bob Ham)
Date: Thu, 03 May 2007 15:29:45 +0100
Subject: [freenet-dev] Cache and Store
Message-ID: <1178202585.10595.9.camel@localhost>

Hi there,

What's the difference between the key Cache and the key Store, as
described on the statistics page?  What are the conditions for the keys
going into and out of the two stores?

Also, I understand that the configured store size limit is split exactly
50:50 between the two.  This is a problem.  Only a very small percentage
of the Store is in use, but the Cache is nearing full.  I've allocated
as much space through the configuration page as I'm prepared to give.  A
very large portion of this space (about 40%) is wasted; it's not being
used by the Store while it could be used by the Cache.  I want to assign
different limits to each set of keys.  Is there a reason this can't
happen?

Regards,

Bob

-- 
Bob Ham <rah at bash.sh>


From toad at amphibian.dyndns.org  Thu May  3 14:48:58 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 15:48:58 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <4639D82F.5040709@cs.ucl.ac.uk>
References: <5172132.1177437285862.JavaMail.root@web34>
	<4633EE54.6070802@cs.ucl.ac.uk>
	<20070502142526.GD23783@amphibian.dyndns.org>
	<4639D82F.5040709@cs.ucl.ac.uk>
Message-ID: <20070503144858.GD24370@amphibian.dyndns.org>

On Thu, May 03, 2007 at 01:40:15PM +0100, Michael Rogers wrote:
> Matthew Toseland wrote:
> >> Of course we don't
> >> want to stay in small, isolated networks forever; ideally we'd set up
> >> small networks with our friends and merge them into the big network
> >> later, but unfortunately I don't think Freenet's architecture can
> >> accommodate that.
> > 
> > Why not? Because small, isolated networks are useless?
> 
> That's a pretty strong statement - are you talking about isolated
> Freenet networks or isolated networks in general? Because there are a
> lot of people using Direct Connect (not to mention private IRC channels,
> FTP servers, etc etc).

Small isolated Freenet networks are of little value because we provide
none of the features that would make them useful at present.
> 
> Clearly the "one big network" approach and the "many small networks"
> approach both have their advantages. For example, you have no anonymity
> on a small network. On the other hand it's easier to find people to peer
> with - if you don't know any members of the big network, just start your
> own network with a couple of friends.
> 
> All I'm trying to say is that in an ideal world we'd get the advantages
> of both approaches if people could set up their own small networks and
> later merge them into the big network.

Of course. But to do that we have to make small isolated Freenet's
useful.
> 
> Cheers,
> Michael
-------------- 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/20070503/1dafacb5/attachment.pgp 

From toad at amphibian.dyndns.org  Thu May  3 14:50:14 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 15:50:14 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <4639D902.5020604@cs.ucl.ac.uk>
References: <10498389.1178130077986.JavaMail.root@web24>
	<4639D902.5020604@cs.ucl.ac.uk>
Message-ID: <20070503145014.GE24370@amphibian.dyndns.org>

On Thu, May 03, 2007 at 01:43:46PM +0100, Michael Rogers wrote:
> jdaviestx wrote:
> > I'm curious - for those of you who have had success with the Darknet approach, how did you approach your peers?  Did you happen to know in person three people who frequent this mailing list, or did you e-mail a link to the freenet home page to a few friends and say "are you interested?"
> > 
> > Once you did... what was on your network?  Were you all pulling things off of Usenet and WWW or ripping CD tracks and injecting them into your personal network?  Did you find it worthwhile?
> 
> Sorry if I'm misunderstanding, but are you suggesting that people have
> already set up private Freenet networks? That's not something that had
> occured to me. Wouldn't we get horrible b0rkage if somebody accidentally
> bridged two networks? Maybe if people are really setting up private
> networks we should introduce some kind of network name (like WASTE has)
> to prevent accidental bridging?

Don't we _want_ the networks to be bridged?

I agree that long term we will need to be able to identify that two
networks are not strongly connected, and treat them as separate
networks, only escaping to the second network if we can't find what we
want on the first ... But that's a long way off.
> 
> Cheers,
> Michael
-------------- 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/20070503/40bc505e/attachment.pgp 

From toad at amphibian.dyndns.org  Thu May  3 14:51:43 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 15:51:43 +0100
Subject: [freenet-dev] Cache and Store
In-Reply-To: <1178202585.10595.9.camel@localhost>
References: <1178202585.10595.9.camel@localhost>
Message-ID: <20070503145143.GF24370@amphibian.dyndns.org>

Take it to -tech please.

On Thu, May 03, 2007 at 03:29:45PM +0100, Bob Ham wrote:
> Hi there,
> 
> What's the difference between the key Cache and the key Store, as
> described on the statistics page?  What are the conditions for the keys
> going into and out of the two stores?
> 
> Also, I understand that the configured store size limit is split exactly
> 50:50 between the two.  This is a problem.  Only a very small percentage
> of the Store is in use, but the Cache is nearing full.  I've allocated
> as much space through the configuration page as I'm prepared to give.  A
> very large portion of this space (about 40%) is wasted; it's not being
> used by the Store while it could be used by the Cache.  I want to assign
> different limits to each set of keys.  Is there a reason this can't
> happen?
> 
> Regards,
> 
> Bob
-------------- 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/20070503/dd4a01ce/attachment.pgp 

From rah at bash.sh  Thu May  3 15:16:13 2007
From: rah at bash.sh (Bob Ham)
Date: Thu, 03 May 2007 16:16:13 +0100
Subject: [freenet-dev] Cache and Store
In-Reply-To: <20070503145143.GF24370@amphibian.dyndns.org>
References: <1178202585.10595.9.camel@localhost>
	<20070503145143.GF24370@amphibian.dyndns.org>
Message-ID: <1178205373.10595.11.camel@localhost>

On Thu, 2007-05-03 at 15:51 +0100, Matthew Toseland wrote:
> Take it to -tech please.

That's pretty ridiculous.

Bob

-- 
Bob Ham <rah at bash.sh>


From m.rogers at cs.ucl.ac.uk  Thu May  3 15:51:04 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Thu, 03 May 2007 16:51:04 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070503144858.GD24370@amphibian.dyndns.org>
References: <5172132.1177437285862.JavaMail.root@web34>
	<4633EE54.6070802@cs.ucl.ac.uk>
	<20070502142526.GD23783@amphibian.dyndns.org>
	<4639D82F.5040709@cs.ucl.ac.uk>
	<20070503144858.GD24370@amphibian.dyndns.org>
Message-ID: <463A04E8.4020304@cs.ucl.ac.uk>

Matthew Toseland wrote:
> Small isolated Freenet networks are of little value because we provide
> none of the features that would make them useful at present.

OK I see what you mean now. I agree that small Freenets aren't very
useful - something like WASTE or Direct Connect is probably more
suitable for a small, trusted group.

> Of course. But to do that we have to make small isolated Freenet's
> useful.

Not only that - you have to solve the problem of merging two mature
networks. I don't think the swapping or routing algorithms would cope
very well with that, which is why I classify Freenet in the "one big
network" category.

Cheers,
Michael


From m.rogers at cs.ucl.ac.uk  Thu May  3 15:56:19 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Thu, 03 May 2007 16:56:19 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070503145014.GE24370@amphibian.dyndns.org>
References: <10498389.1178130077986.JavaMail.root@web24>
	<4639D902.5020604@cs.ucl.ac.uk>
	<20070503145014.GE24370@amphibian.dyndns.org>
Message-ID: <463A0623.1010903@cs.ucl.ac.uk>

Matthew Toseland wrote:
> Don't we _want_ the networks to be bridged?

Not at present - a few links between two mature networks (which is what
I mean by bridging, sorry if that's the wrong terminology) would break
things pretty badly I believe. The bridge nodes would be little better
than black holes.

> I agree that long term we will need to be able to identify that two
> networks are not strongly connected, and treat them as separate
> networks, only escaping to the second network if we can't find what we
> want on the first ... But that's a long way off.

Fair enough, I'm not trying to push for it, just brainstorming about
advantages and disadvantages of different darknet architectures.

Cheers,
Michael


From toad at amphibian.dyndns.org  Thu May  3 18:07:37 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 19:07:37 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <463A0623.1010903@cs.ucl.ac.uk>
References: <10498389.1178130077986.JavaMail.root@web24>
	<4639D902.5020604@cs.ucl.ac.uk>
	<20070503145014.GE24370@amphibian.dyndns.org>
	<463A0623.1010903@cs.ucl.ac.uk>
Message-ID: <20070503180737.GI24370@amphibian.dyndns.org>

On Thu, May 03, 2007 at 04:56:19PM +0100, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Don't we _want_ the networks to be bridged?
> 
> Not at present - a few links between two mature networks (which is what
> I mean by bridging, sorry if that's the wrong terminology) would break
> things pretty badly I believe. The bridge nodes would be little better
> than black holes.
> 
> > I agree that long term we will need to be able to identify that two
> > networks are not strongly connected, and treat them as separate
> > networks, only escaping to the second network if we can't find what we
> > want on the first ... But that's a long way off.
> 
> Fair enough, I'm not trying to push for it, just brainstorming about
> advantages and disadvantages of different darknet architectures.

We should support it sure, but it's lower priority than opennet. Start a
wiki page if you want. :)
> 
> Cheers,
> Michael
-------------- 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/20070503/59db558b/attachment.pgp 

From toad at amphibian.dyndns.org  Thu May  3 18:08:38 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 3 May 2007 19:08:38 +0100
Subject: [freenet-dev] Cache and Store
In-Reply-To: <1178205373.10595.11.camel@localhost>
References: <1178202585.10595.9.camel@localhost>
	<20070503145143.GF24370@amphibian.dyndns.org>
	<1178205373.10595.11.camel@localhost>
Message-ID: <20070503180838.GJ24370@amphibian.dyndns.org>

On Thu, May 03, 2007 at 04:16:13PM +0100, Bob Ham wrote:
> On Thu, 2007-05-03 at 15:51 +0100, Matthew Toseland wrote:
> > Take it to -tech please.
> 
> That's pretty ridiculous.

Is it relevant to the development of the next few builds of Freenet? If
not, it's a matter for the tech list. This is the development list.
-------------- 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/20070503/d7441c1e/attachment.pgp 

From rah at bash.sh  Thu May  3 20:44:50 2007
From: rah at bash.sh (Bob Ham)
Date: Thu, 03 May 2007 21:44:50 +0100
Subject: [freenet-dev] Cache and Store
In-Reply-To: <20070503180838.GJ24370@amphibian.dyndns.org>
References: <1178202585.10595.9.camel@localhost>
	<20070503145143.GF24370@amphibian.dyndns.org>
	<1178205373.10595.11.camel@localhost>
	<20070503180838.GJ24370@amphibian.dyndns.org>
Message-ID: <1178225090.20059.0.camel@orchid.arb.net>

On Thu, 2007-05-03 at 19:08 +0100, Matthew Toseland wrote:
> On Thu, May 03, 2007 at 04:16:13PM +0100, Bob Ham wrote:
> > On Thu, 2007-05-03 at 15:51 +0100, Matthew Toseland wrote:
> > > Take it to -tech please.
> > 
> > That's pretty ridiculous.
> 
> Is it relevant to the development of the next few builds of Freenet? If
> not, it's a matter for the tech list. This is the development list.

What's ridiculous is that such matters are separated so.

Bob

-- 
Bob Ham <rah at bash.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070503/0bac79a1/attachment.pgp 

From Volodya at WhenGendarmeSleeps.org  Sun May  6 08:15:49 2007
From: Volodya at WhenGendarmeSleeps.org (Volodya)
Date: Sun, 06 May 2007 09:15:49 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <4639D902.5020604@cs.ucl.ac.uk>
References: <10498389.1178130077986.JavaMail.root@web24>
	<4639D902.5020604@cs.ucl.ac.uk>
Message-ID: <463D8EB5.5010509@WhenGendarmeSleeps.org>

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

Michael Rogers wrote:
> jdaviestx wrote:
>> I'm curious - for those of you who have had success with the Darknet approach, how did you approach your peers?  Did you happen to know in person three people who frequent this mailing list, or did you e-mail a link to the freenet home page to a few friends and say "are you interested?"
>>
>> Once you did... what was on your network?  Were you all pulling things off of Usenet and WWW or ripping CD tracks and injecting them into your personal network?  Did you find it worthwhile?
> 
> Sorry if I'm misunderstanding, but are you suggesting that people have
> already set up private Freenet networks? That's not something that had
> occured to me. Wouldn't we get horrible b0rkage if somebody accidentally
> bridged two networks? Maybe if people are really setting up private
> networks we should introduce some kind of network name (like WASTE has)
> to prevent accidental bridging?
> 
> Cheers,
> Michael

Why would you want to do that? After all if somebody is willing to act as a bridge it's
that much better. Of course that person will have to stay online for a long time, and
things like frost boards would probably misbehave when that person is offline.

Bridging networks that already exist should be encouraged i think.

- --
http://freedom.libsyn.com/       Voice of Freedom, Radical Podcast
http://freeselfdefence.info/     Self-defence wiki
http://www.kingstonstudents.org/ Kingston University students' forum

 "None of us are free until all of us are free."    ~ Mihail Bakunin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFGPY60uWy2EFICg+0RAuRgAJ4gLoWERnKLRves1O0imB+VEdg4QACgwYEx
JgX2jBdGlwtlMJaKEUGXknE=
=rv+h
-----END PGP SIGNATURE-----


From Volodya at WhenGendarmeSleeps.org  Sun May  6 08:19:18 2007
From: Volodya at WhenGendarmeSleeps.org (Volodya)
Date: Sun, 06 May 2007 09:19:18 +0100
Subject: [freenet-dev] Story Submitted to Slashdot
In-Reply-To: <20070503144858.GD24370@amphibian.dyndns.org>
References: <5172132.1177437285862.JavaMail.root@web34>	<4633EE54.6070802@cs.ucl.ac.uk>	<20070502142526.GD23783@amphibian.dyndns.org>	<4639D82F.5040709@cs.ucl.ac.uk>
	<20070503144858.GD24370@amphibian.dyndns.org>
Message-ID: <463D8F86.8050106@WhenGendarmeSleeps.org>

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

> Of course. But to do that we have to make small isolated Freenet's
> useful.

Why wouldn't they already be useful?

Let's say i decide to set up Freenet amongst university students, we can have a propper
anonymous communication via Freenet just like people do on the global scale. Now let's
assume that lecturers already have Freenet setup amongst themselves, then somebody could
bridge who networks, and the network as the whole would grow. More than one bridge would
of course be preferred.

                   - VolodyA! V A

- --
http://freedom.libsyn.com/       Voice of Freedom, Radical Podcast
http://freeselfdefence.info/     Self-defence wiki
http://www.kingstonstudents.org/ Kingston University students' forum

 "None of us are free until all of us are free."    ~ Mihail Bakunin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFGPY+GuWy2EFICg+0RAuQHAJ49UAcMbVOGpdOoixvzfOfkSRj4VQCfdh8C
RWUaoZBiqwgGyowi4xb4NkU=
=kuhl
-----END PGP SIGNATURE-----


From m.rogers at cs.ucl.ac.uk  Sun May  6 14:59:22 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Sun, 06 May 2007 15:59:22 +0100
Subject: [freenet-dev] Can I take it to the bridge? (Re: Story Submitted to
 Slashdot)
In-Reply-To: <463D8F86.8050106@WhenGendarmeSleeps.org>
References: <5172132.1177437285862.JavaMail.root@web34>
	<4633EE54.6070802@cs.ucl.ac.uk>
	<20070502142526.GD23783@amphibian.dyndns.org>
	<4639D82F.5040709@cs.ucl.ac.uk>
	<20070503144858.GD24370@amphibian.dyndns.org>
	<463D8F86.8050106@WhenGendarmeSleeps.org>
Message-ID: <463DED4A.6060505@cs.ucl.ac.uk>

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

Volodya wrote:
>> Of course. But to do that we have to make small isolated Freenet's
>> useful.
> 
> Why wouldn't they already be useful?
> 
> Let's say i decide to set up Freenet amongst university students, we can have a propper
> anonymous communication via Freenet just like people do on the global scale. Now let's
> assume that lecturers already have Freenet setup amongst themselves, then somebody could
> bridge who networks, and the network as the whole would grow. More than one bridge would
> of course be preferred.

In theory that would be a great idea - it would probably be easier to
grow a large darknet from multiple seeds than a single seed - but in
practise I think it would cause problems for routing.

Let's say there are two separate mature networks. Each network has been
running the swapping algorithm for a while, so the node locations are
well distributed for greedy routing. Now somebody bridges the two networks.

If a key is inserted into network A and the insert reaches the bridge
node, there's a 50% chance it will stay in network A and a 50% chance it
will cross over into network B (all other things being equal). If it
crosses over, requests for the key originating in network A will only
succeed if they also happen to reach the bridge node. So if you happen
to be close to the bridge node, a lot of the keys you insert will cross
over, and other people who are further from the bridge node will have
trouble retrieving them.

A second issue is swapping: I'm not sure how the swapping algorithm
would handle a network consisting of two fairly dense components
connected by one or two bridges. My guess is that it would try to assign
one half of the keyspace to each component. If it succeeded, half the
requests and inserts in the network would have to travel across the
bridges, and routing would be completely broken when the bridges were
offline. Unfortunately if I'm right about this, there's a more serious
risk than someone accidentally bridging two networks: someone might
create a Sybil network of a few hundred nodes, connected to the real
network by a handful of bridges, in order to knock out a random arc of
the keyspace.

Cheers,
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGPe1Kyua14OQlJ3sRAqD1AJ41rUgmT0la7y0xhZR4FYYQDndmpQCfQXNU
WlWLYfQtnE5KlAnjmWq4vbs=
=ieTP
-----END PGP SIGNATURE-----


From juiceman69 at gmail.com  Thu May 10 03:36:25 2007
From: juiceman69 at gmail.com (Juiceman)
Date: Wed, 9 May 2007 23:36:25 -0400
Subject: [freenet-dev] [freenet-cvs] r13163 -
	trunk/freenet/src/freenet/l10n
In-Reply-To: <200705091646.39832.toad@amphibian.dyndns.org>
References: <20070507184308.1FA18479919@emu.freenetproject.org>
	<200705091646.39832.toad@amphibian.dyndns.org>
Message-ID: <8b525dee0705092036p59277995qe81c721a3b40f2ec@mail.gmail.com>

Ok, I will be very careful of any future spacing issues.
I would agree that the space should be coded in, otherwise the
translators will need to be sure to keep the same spacing which imho
they shouldn't need to worry about.

I will go thru the code for the items I changed and code in a space
where needed when I get time soon.

CCing to devl list

On 5/9/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> Sometimes trailing spaces are intentional (look at the error page you get in
> fproxy for example when a file is too big: there should be a space after the
> colon in the details box). Maybe we shouldn't do that, maybe we should always
> add a space in the code where that happens though.
>
> On Monday 07 May 2007 19:43, juiceman at freenetproject.org wrote:
> > Author: juiceman
> > Date: 2007-05-07 18:43:08 +0000 (Mon, 07 May 2007)
> > New Revision: 13163
> >
> > Modified:
> >    trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
> > Log:
> > Spelling, typos, trailing spaces, capitalization (Please capitalize Freenet
> > when not used as a variable or URL)  Be consistent.
> >
> > Modified: trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
> > ===================================================================
> > --- trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties 2007-05-07
> > 09:31:44 UTC (rev 13162) +++
> > trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties     2007-05-07
> > 18:43:08 UTC (rev 13163) @@ -78,7 +78,7 @@
> >  InsertException.shortError.11=Meta string used in the key
> >  InsertException.longError.11=Meta string (most likely a '/') used in the
> > URI Toadlet.internalErrorTitle=Internal Error
> > -Toadlet.internalErrorPleaseReport=Internal error : please report
> > +Toadlet.internalErrorPleaseReport=Internal error: please report
> >  Toadlet.unauthorized=You are not permitted access to this page.


-- 
I may disagree with what you have to say, but I shall defend, to the
death, your right to say it. - Voltaire
Those who would give up Liberty, to purchase temporary Safety, deserve
neither Liberty nor Safety. - Ben Franklin


From luke771 at gmail.com  Sat May  5 07:27:35 2007
From: luke771 at gmail.com (Luke771)
Date: Sat, 05 May 2007 09:27:35 +0200
Subject: [freenet-dev] it. transl. ph00 v.11
Message-ID: <463C31E7.8030004@gmail.com>

updated to r13152
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v11
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070505/8b2067f9/attachment.txt 

From luke771 at gmail.com  Tue May  8 05:10:27 2007
From: luke771 at gmail.com (Luke771)
Date: Tue, 08 May 2007 07:10:27 +0200
Subject: [freenet-dev] it. transl.  v.12 ph00
Message-ID: <46400643.1010301@gmail.com>

updated to r13166
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v12
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070508/c3840f19/attachment.txt 

From toad at amphibian.dyndns.org  Thu May 10 10:38:22 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 10 May 2007 11:38:22 +0100
Subject: [freenet-dev] it. transl.  v.12 ph00
In-Reply-To: <46400643.1010301@gmail.com>
References: <46400643.1010301@gmail.com>
Message-ID: <200705101138.25715.toad@amphibian.dyndns.org>

Committed, thanks.

On Tuesday 08 May 2007 06:10, Luke771 wrote:
> updated to r13166
-------------- 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/20070510/76bae147/attachment.pgp 

From nextgens at freenetproject.org  Thu May 10 10:48:52 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Thu, 10 May 2007 12:48:52 +0200
Subject: [freenet-dev] [freenet-cvs] r13163 -
	trunk/freenet/src/freenet/l10n
In-Reply-To: <8b525dee0705092036p59277995qe81c721a3b40f2ec@mail.gmail.com>
References: <20070507184308.1FA18479919@emu.freenetproject.org>
	<200705091646.39832.toad@amphibian.dyndns.org>
	<8b525dee0705092036p59277995qe81c721a3b40f2ec@mail.gmail.com>
Message-ID: <20070510104852.GD5480@freenetproject.org>

* Juiceman <juiceman69 at gmail.com> [2007-05-09 23:36:25]:

> Ok, I will be very careful of any future spacing issues.
> I would agree that the space should be coded in, otherwise the
> translators will need to be sure to keep the same spacing which imho
> they shouldn't need to worry about.
> 
> I will go thru the code for the items I changed and code in a space
> where needed when I get time soon.
> 
> CCing to devl list

I don't think that we should re-indent all the code now.
It produces very huge diffs and those are painfull to review.

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/20070510/b6d71b90/attachment.pgp 

From toad at amphibian.dyndns.org  Thu May 10 15:22:43 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 10 May 2007 16:22:43 +0100
Subject: [freenet-dev] [freenet-cvs] r13163 -
	trunk/freenet/src/freenet/l10n
In-Reply-To: <20070510104852.GD5480@freenetproject.org>
References: <20070507184308.1FA18479919@emu.freenetproject.org>
	<8b525dee0705092036p59277995qe81c721a3b40f2ec@mail.gmail.com>
	<20070510104852.GD5480@freenetproject.org>
Message-ID: <200705101622.49159.toad@amphibian.dyndns.org>

On Thursday 10 May 2007 11:48, Florent Daigni?re wrote:
> * Juiceman <juiceman69 at gmail.com> [2007-05-09 23:36:25]:
> > Ok, I will be very careful of any future spacing issues.
> > I would agree that the space should be coded in, otherwise the
> > translators will need to be sure to keep the same spacing which imho
> > they shouldn't need to worry about.
> >
> > I will go thru the code for the items I changed and code in a space
> > where needed when I get time soon.
> >
> > CCing to devl list
>
> I don't think that we should re-indent all the code now.
> It produces very huge diffs and those are painfull to review.
>
> NextGen$

They can be quickly reviewed using the verify snapshot script in the 
maintenance scripts directory.
-------------- 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/20070510/327eab88/attachment.pgp 

From toad at amphibian.dyndns.org  Thu May 10 21:28:43 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Thu, 10 May 2007 22:28:43 +0100
Subject: [freenet-dev] Freenet 0.7 build 1032 and call for translators
Message-ID: <200705102228.44271.toad@amphibian.dyndns.org>

Freenet 0.7 build 1032 is now available. Please upgrade (it should be on the 
auto-update system very soon, tell us if that doesn't work).

The main change in 1032 is the completion of the localisation framework. What 
this means is that the node is now ready for the user interface to be 
translated. Translation keys have been added for all strings that a 
non-developer user is likely to see through the web interface. More strings 
may be added later on due to new features, and it's possible that some may be 
combined because they are the same, but generally speaking it is ready for 
translators to start work. If you want to translate Freenet into your native 
language, please contact us, and use the built-in functionality of your node 
to do it: set your language on the config page (set it to unlisted if your 
language isn't there already), and use the Translation page to translate 
strings. Then download the translation file and send us it (by any means), 
and we will try to include it in the next version. Also if you can review 
translations to see if they are reasonable that is also useful. Thanks to 
_ph00 and Cooo for providing (mostly but not quite complete) Italian and 
Swedish translations.

There are also various bugfixes including in the client layer, web interface 
and datastore. Please upgrade.
-------------- 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/20070510/7a568e3b/attachment.pgp 

From luke771 at gmail.com  Sat May 12 03:33:37 2007
From: luke771 at gmail.com (Luke771)
Date: Sat, 12 May 2007 05:33:37 +0200
Subject: [freenet-dev] it.transl. v.16 ph00
Message-ID: <46453591.5050300@gmail.com>

file attached
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: freenet.l10n.it.override.properties.ph00.v16
Url: http://emu.freenetproject.org/pipermail/devl/attachments/20070512/6112eafb/attachment.txt 

From toad at amphibian.dyndns.org  Wed May 16 11:53:57 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 16 May 2007 12:53:57 +0100
Subject: [freenet-dev] "Why did you uninstall" - what options to show
Message-ID: <200705161254.04662.toad@amphibian.dyndns.org>

Currently on uninstalling (on Windows), we show the user a list of options:

I wasn't able to get it running!
It lacks content.
I was deceived by the content I found
It's just too slow!

This does not distinguish between problems with references and problems with 
the installer.

What options should we include? One possibility, but it's a bit too long for 
my liking (10 options):

It wouldn't even install!
It installed but didn't work at all (e.g. I couldn't get the web interface)!
I tried to get node references but couldn't find anyone to trade with
I added some node references but it still didn't work
I don't know what IRC is
I don't want to mess with node references, so I didn't try
I don't want to connect to total strangers and no friends are on Freenet
It lacks content.
I was deceived by the content I found
It's just too slow!

Any comments? Anything we absolutely must cover but don't?
-------------- 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/20070516/1f7aeed2/attachment.pgp 

From m.rogers at cs.ucl.ac.uk  Wed May 16 13:04:05 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Wed, 16 May 2007 14:04:05 +0100
Subject: [freenet-dev] "Why did you uninstall" - what options to show
In-Reply-To: <200705161254.04662.toad@amphibian.dyndns.org>
References: <200705161254.04662.toad@amphibian.dyndns.org>
Message-ID: <464B0145.1030805@cs.ucl.ac.uk>

Matthew Toseland wrote:
> It wouldn't even install!
> It installed but didn't work at all (e.g. I couldn't get the web interface)!
> I tried to get node references but couldn't find anyone to trade with
> I added some node references but it still didn't work
> I don't know what IRC is
> I don't want to mess with node references, so I didn't try
> I don't want to connect to total strangers and no friends are on Freenet
> It lacks content.
> I was deceived by the content I found
> It's just too slow!

Would it be possible for the node to log the first time it's started, 
the first time a reference is added and the first time a key is 
successfully received? Then the uninstaller could automatically report 
that information (no times or details, just the fact that it happened), 
and maybe we could reduce the options to something more general, eg

Problems installing or configuring the software
Problems finding or connecting to peers
Problems uploading or downloading content
Performance problems
Secret police kicking are my door down (actually maybe this one should 
go at the top)

Cheers,
Michael


From freenet-devl at kork.dyndns.org  Wed May 16 13:07:19 2007
From: freenet-devl at kork.dyndns.org (Marco Gruss)
Date: Wed, 16 May 2007 15:07:19 +0200
Subject: [freenet-dev] "Why did you uninstall" - what options to show
In-Reply-To: <464B0145.1030805@cs.ucl.ac.uk>
References: <200705161254.04662.toad@amphibian.dyndns.org>
	<464B0145.1030805@cs.ucl.ac.uk>
Message-ID: <464B0207.6080501@kork.dyndns.org>

Hi,

Michael Rogers wrote:
> Would it be possible for the node to log the first time it's started, 
> the first time a reference is added and the first time a key is 
> successfully received? Then the uninstaller could automatically report 
> that information (no times or details, just the fact that it happened), 
> and maybe we could reduce the options to something more general, eg
If this is implemented, it should DEFINITELY be made absolutely clear
and OPTIONAL. Otherwise, I bet there'll be cries of spyware and phoning
home all over the place.

Marco


From m.rogers at cs.ucl.ac.uk  Wed May 16 13:21:36 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Wed, 16 May 2007 14:21:36 +0100
Subject: [freenet-dev] "Why did you uninstall" - what options to show
In-Reply-To: <464B0207.6080501@kork.dyndns.org>
References: <200705161254.04662.toad@amphibian.dyndns.org>
	<464B0145.1030805@cs.ucl.ac.uk> <464B0207.6080501@kork.dyndns.org>
Message-ID: <464B0560.8060807@cs.ucl.ac.uk>

Marco Gruss wrote:
>> Would it be possible for the node to log the first time it's started, 
>> the first time a reference is added and the first time a key is 
>> successfully received? Then the uninstaller could automatically report 
>> that information (no times or details, just the fact that it happened), 
>> and maybe we could reduce the options to something more general, eg
> If this is implemented, it should DEFINITELY be made absolutely clear
> and OPTIONAL. Otherwise, I bet there'll be cries of spyware and phoning
> home all over the place.

Good point, it shouldn't send any information without asking the user!

Cheers,
Michael


From toad at amphibian.dyndns.org  Wed May 16 15:04:59 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Wed, 16 May 2007 16:04:59 +0100
Subject: [freenet-dev] More database/datastore problems
Message-ID: <200705161605.05345.toad@amphibian.dyndns.org>

Berkeley DB Java Edition is not sufficiently robust for our usage. By robust I 
mean we need to be able to automatically recover from a corrupted datastore 
on startup. We cannot do this with BDBJE. At least, not without a lot of 
hacking...

My latest effort was to try to automatically use the documented recovery 
procedure of DbDump -r and DbLoad. The problem is that this produces 
duplicate elements in the database, which cannot afaics be cleaned 
automatically. This results in it being impossible to reconstruct the 
secondary index for block numbers. Observe:

INFO   | jvm 1    | 2007/05/16 15:10:47 | Opening block db index
INFO   | jvm 1    | 2007/05/16 15:10:49 | Database chk-cache-CHK_blockNum does 
not exist deleting it
INFO   | jvm 1    | 2007/05/16 15:10:49 | Reconstructing block numbers 
index... (com.sleepycat.je.DatabaseNotFoundException: (JE 3.2.23) Database 
chk-cache-CHK_blockNum not found.)
INFO   | jvm 1    | 2007/05/16 15:10:49 | Creating new block DB index
INFO   | jvm 1    | 2007/05/16 15:10:58 | Error opening block nums db: 
com.sleepycat.je.DatabaseException: (JE 3.2.23) Could not insert secondary 
key in chk-cache-CHK_blockNum OperationStatus.KEYEXIST
INFO   | jvm 1    | 2007/05/16 15:10:58 | com.sleepycat.je.DatabaseException: 
(JE 3.2.23) Could not insert secondary key in chk-cache-CHK_blockNum 
OperationStatus.KEYEXIST
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
com.sleepycat.je.SecondaryDatabase.insertKey(SecondaryDatabase.java:698)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
com.sleepycat.je.SecondaryDatabase.updateSecondary(SecondaryDatabase.java:567)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
com.sleepycat.je.SecondaryDatabase.init(SecondaryDatabase.java:181)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
com.sleepycat.je.SecondaryDatabase.initNew(SecondaryDatabase.java:118)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
com.sleepycat.je.Environment.openDb(Environment.java:473)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
com.sleepycat.je.Environment.openSecondaryDatabase(Environment.java:375)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
freenet.store.BerkeleyDBFreenetStore.<init>(BerkeleyDBFreenetStore.java:639)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
freenet.store.BerkeleyDBFreenetStore.openStore(BerkeleyDBFreenetStore.java:383)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
freenet.store.BerkeleyDBFreenetStore.construct(BerkeleyDBFreenetStore.java:150)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
freenet.node.Node.<init>(Node.java:1333)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
freenet.node.NodeStarter.start(NodeStarter.java:148)
INFO   | jvm 1    | 2007/05/16 15:10:58 |       at 
org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)

What the code has done is dumped the databases into .dump files using DbDump, 
deleted the old logs, and restored them via DbLoad. The secondary indexes (on 
access time and block number) are to be restored. On access time, duplicates 
are allowed, but on block number, duplicates are not allowed, because only 
one key can be stored in any given block. At the beginning of the above, the 
secondary index does not exist:
Reconstructing block numbers index... 
(com.sleepycat.je.DatabaseNotFoundException: (JE 3.2.23) Database 
chk-cache-CHK_blockNum not found.)

So we open the secondary database with AllowCreate and AllowPopulate enabled. 
And it throws a DatabaseException as above, as far as I can see because there 
are blocks recovered in the main database with the same block number. So our 
code picks this up and takes the only option available to it: It deletes the 
database and reconstructs from the contents of the store file. There are two 
main problems with this:
1) It doesn't work at all for SSKs. The SSK store is dropped on every 
reconstruction, because we don't have the key, and can't generate it from the 
headers. The fix is to store the key somewhere. We will do this, eventually.
2) It doesn't restore the LRU order of the stored data. A fix for this would 
be to store the access time counter somewhere on disk too.

So our options are:
1) Open the block numbers database with sorted duplicates enabled. Then scan 
through it for dupes, keep the correct one in each case, close the database, 
and re-open it again with sorted duplicates disabled.
2) Keep the block numbers index open with sorted duplicates enabled. When we 
need to look up a block number, deal with the fact that there may be multiple 
keys referring to it, and delete as appropriate. Deal with the fact that this 
may cause keys in the main database that don't exist in the store.
3) Improve the data stored on disk: Store the LRU access time, and the key, on 
disk. Probably we would need migration code.
4) Use a completely different database for the index.
5) Use a completely different database for the whole store, and trust it not 
to lose the data. (from our experience with BDB, it is likely that it will!)
6) Roll our own database code.
-------------- 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/20070516/7e6fc42b/attachment.pgp 

From m.rogers at cs.ucl.ac.uk  Wed May 16 16:13:15 2007
From: m.rogers at cs.ucl.ac.uk (Michael Rogers)
Date: Wed, 16 May 2007 17:13:15 +0100
Subject: [freenet-dev] More database/datastore problems
In-Reply-To: <200705161605.05345.toad@amphibian.dyndns.org>
References: <200705161605.05345.toad@amphibian.dyndns.org>
Message-ID: <464B2D9B.2080809@cs.ucl.ac.uk>

Matthew Toseland wrote:
> 4) Use a completely different database for the index.
> 5) Use a completely different database for the whole store, and trust it not 
> to lose the data. (from our experience with BDB, it is likely that it will!)
> 6) Roll our own database code.

7) Get rid of the secondary indices: store the data in the database 
instead of in files, removing the need to store block numbers, and use 
random deletion instead of LRU, removing the need to store the access time.

Disclaimers:

1. I understand that it's not currently a good idea to store the data in 
the database because we lose everything if the database gets corrupted, 
but if getting rid of the secondary indices fixes the corruption 
problems then that will no longer be an issue.

2. I'm not pushing for LRU to be replaced, the issue just happens to 
have cropped up twice in a short period for different reasons. :-)

Cheers,
Michael


From carlin at jlab.org  Wed May 16 17:42:33 2007
From: carlin at jlab.org (Chris Carlin)
Date: Wed, 16 May 2007 13:42:33 -0400
Subject: [freenet-dev] More database/datastore problems
In-Reply-To: <200705161605.05345.toad@amphibian.dyndns.org>
References: <200705161605.05345.toad@amphibian.dyndns.org>
Message-ID: <464B4289.7090608@jlab.org>


> So our options are:
> 1) Open the block numbers database with sorted duplicates enabled. Then scan 
> through it for dupes, keep the correct one in each case, close the database, 
> and re-open it again with sorted duplicates disabled.
> 2) Keep the block numbers index open with sorted duplicates enabled. When we 
> need to look up a block number, deal with the fact that there may be multiple 
> keys referring to it, and delete as appropriate. Deal with the fact that this 
> may cause keys in the main database that don't exist in the store.
> 3) Improve the data stored on disk: Store the LRU access time, and the key, on 
> disk. Probably we would need migration code.
> 4) Use a completely different database for the index.
> 5) Use a completely different database for the whole store, and trust it not 
> to lose the data. (from our experience with BDB, it is likely that it will!)
> 6) Roll our own database code.

It seems to me that BDB has been rejected as the proper solution 
multiple times on this mailing list. Maybe I misunderstood, but in 
particular I remember when I was going to follow up with Oracle about 
memory usage issues but stopped when consensus seemed to find that BDB 
wasn't worth pursuing for various other reasons.

~Chris


From bbackde at googlemail.com  Wed May 16 18:15:28 2007
From: bbackde at googlemail.com (bbackde at googlemail.com)
Date: Wed, 16 May 2007 20:15:28 +0200
Subject: [freenet-dev] More database/datastore problems
In-Reply-To: <464B4289.7090608@jlab.org>
References: <200705161605.05345.toad@amphibian.dyndns.org>
	<464B4289.7090608@jlab.org>
Message-ID: <d6149a790705161115n6fa34d22x5c99f07819435e2d@mail.gmail.com>

> 6) Roll our own database code.

Better don't try to make it better by yourself what other teams did
not accomplish. IF there is no crash-stable free DB outside there, its
maybe not possible to code one.

Try DB/2 Express ;)

On 5/16/07, Chris Carlin <carlin at jlab.org> wrote:
>
> > So our options are:
> > 1) Open the block numbers database with sorted duplicates enabled. Then scan
> > through it for dupes, keep the correct one in each case, close the database,
> > and re-open it again with sorted duplicates disabled.
> > 2) Keep the block numbers index open with sorted duplicates enabled. When we
> > need to look up a block number, deal with the fact that there may be multiple
> > keys referring to it, and delete as appropriate. Deal with the fact that this
> > may cause keys in the main database that don't exist in the store.
> > 3) Improve the data stored on disk: Store the LRU access time, and the key, on
> > disk. Probably we would need migration code.
> > 4) Use a completely different database for the index.
> > 5) Use a completely different database for the whole store, and trust it not
> > to lose the data. (from our experience with BDB, it is likely that it will!)
> > 6) Roll our own database code.
>
> It seems to me that BDB has been rejected as the proper solution
> multiple times on this mailing list. Maybe I misunderstood, but in
> particular I remember when I was going to follow up with Oracle about
> memory usage issues but stopped when consensus seemed to find that BDB
> wasn't worth pursuing for various other reasons.
>
> ~Chris
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>


From nextgens at freenetproject.org  Wed May 16 23:31:22 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Thu, 17 May 2007 01:31:22 +0200
Subject: [freenet-dev] More database/datastore problems
In-Reply-To: <464B4289.7090608@jlab.org>
References: <200705161605.05345.toad@amphibian.dyndns.org>
	<464B4289.7090608@jlab.org>
Message-ID: <20070516233121.GB5709@freenetproject.org>

* Chris Carlin <carlin at jlab.org> [2007-05-16 13:42:33]:

> 
> > So our options are:
> > 1) Open the block numbers database with sorted duplicates enabled. Then scan 
> > through it for dupes, keep the correct one in each case, close the database, 
> > and re-open it again with sorted duplicates disabled.
> > 2) Keep the block numbers index open with sorted duplicates enabled. When we 
> > need to look up a block number, deal with the fact that there may be multiple 
> > keys referring to it, and delete as appropriate. Deal with the fact that this 
> > may cause keys in the main database that don't exist in the store.
> > 3) Improve the data stored on disk: Store the LRU access time, and the key, on 
> > disk. Probably we would need migration code.
> > 4) Use a completely different database for the index.
> > 5) Use a completely different database for the whole store, and trust it not 
> > to lose the data. (from our experience with BDB, it is likely that it will!)
> > 6) Roll our own database code.
> 
> It seems to me that BDB has been rejected as the proper solution 
> multiple times on this mailing list. Maybe I misunderstood, but in 
> particular I remember when I was going to follow up with Oracle about 
> memory usage issues but stopped when consensus seemed to find that BDB 
> wasn't worth pursuing for various other reasons.
> 
> ~Chris

We weren't using it properly, hence  the high memory usage we noticed...
Now  toad  is  willing  to  switch to  something  else  because  of  the
"robustness"  criteria  he has  defined  (ability  for the  database  to
auto-repair itself  and perform  catastrophic recovery proceedure  in an
automated  way without  involving  the user).  I do  think  that we  are
looking for a rara avis here :/

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/20070517/425e0e3d/attachment.pgp 

From toad at amphibian.dyndns.org  Fri May 18 15:52:42 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 18 May 2007 16:52:42 +0100
Subject: [freenet-dev] More database/datastore problems
In-Reply-To: <464B2D9B.2080809@cs.ucl.ac.uk>
References: <200705161605.05345.toad@amphibian.dyndns.org>
	<464B2D9B.2080809@cs.ucl.ac.uk>
Message-ID: <200705181652.48488.toad@amphibian.dyndns.org>

On Wednesday 16 May 2007 17:13, Michael Rogers wrote:
> Matthew Toseland wrote:
> > 4) Use a completely different database for the index.
> > 5) Use a completely different database for the whole store, and trust it
> > not to lose the data. (from our experience with BDB, it is likely that it
> > will!) 6) Roll our own database code.
>
> 7) Get rid of the secondary indices: store the data in the database
> instead of in files, removing the need to store block numbers, and use
> random deletion instead of LRU, removing the need to store the access time.

The secondary indexes are by block number and by access time. The first is not 
necessary if we store the data in the database, however see below: It's 
insane.

Also I remain to be convinced that random deletion would do anything other 
than significantly reduce performance. We have a two level datastore for a 
reason; it's perfectly okay IMHO for the cache to cache mostly popular 
content, since we have the store as well.
>
> Disclaimers:
>
> 1. I understand that it's not currently a good idea to store the data in
> the database because we lose everything if the database gets corrupted,
> but if getting rid of the secondary indices fixes the corruption
> problems then that will no longer be an issue.

And if it doesn't, it will be even worse. And the only way to find out is to 
try it. Not a good plan IMHO.
>
> 2. I'm not pushing for LRU to be replaced, the issue just happens to
> have cropped up twice in a short period for different reasons. :-)
>
> 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/20070518/057e670c/attachment.pgp 

From toad at amphibian.dyndns.org  Fri May 18 15:54:16 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 18 May 2007 16:54:16 +0100
Subject: [freenet-dev] More database/datastore problems
In-Reply-To: <20070516233121.GB5709@freenetproject.org>
References: <200705161605.05345.toad@amphibian.dyndns.org>
	<464B4289.7090608@jlab.org>
	<20070516233121.GB5709@freenetproject.org>
Message-ID: <200705181654.17011.toad@amphibian.dyndns.org>

I've more or less decided to implement robustness externally. What this means 
is writing the access times (and for SSKs, the keys) to the store/cache file 
along with the data and headers, so that we can do a 100% reconstruction when 
necessary.

On Thursday 17 May 2007 00:31, Florent Daigni?re wrote:
> * Chris Carlin <carlin at jlab.org> [2007-05-16 13:42:33]:
> > > So our options are:
> > > 1) Open the block numbers database with sorted duplicates enabled. Then
> > > scan through it for dupes, keep the correct one in each case, close the
> > > database, and re-open it again with sorted duplicates disabled.
> > > 2) Keep the block numbers index open with sorted duplicates enabled.
> > > When we need to look up a block number, deal with the fact that there
> > > may be multiple keys referring to it, and delete as appropriate. Deal
> > > with the fact that this may cause keys in the main database that don't
> > > exist in the store. 3) Improve the data stored on disk: Store the LRU
> > > access time, and the key, on disk. Probably we would need migration
> > > code.
> > > 4) Use a completely different database for the index.
> > > 5) Use a completely different database for the whole store, and trust
> > > it not to lose the data. (from our experience with BDB, it is likely
> > > that it will!) 6) Roll our own database code.
> >
> > It seems to me that BDB has been rejected as the proper solution
> > multiple times on this mailing list. Maybe I misunderstood, but in
> > particular I remember when I was going to follow up with Oracle about
> > memory usage issues but stopped when consensus seemed to find that BDB
> > wasn't worth pursuing for various other reasons.
> >
> > ~Chris
>
> We weren't using it properly, hence  the high memory usage we noticed...
> Now  toad  is  willing  to  switch to  something  else  because  of  the
> "robustness"  criteria  he has  defined  (ability  for the  database  to
> auto-repair itself  and perform  catastrophic recovery proceedure  in an
> automated  way without  involving  the user).  I do  think  that we  are
> looking for a rara avis here :/
>
> 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/20070518/8b35dcf8/attachment.pgp 

From toad at amphibian.dyndns.org  Fri May 18 16:35:33 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 18 May 2007 17:35:33 +0100
Subject: [freenet-dev] Pre-tunneling (idea found on wiki)
Message-ID: <200705181735.38891.toad@amphibian.dyndns.org>

http://wiki.freenetproject.org/PreTunneling

Is this of any interest? Is it practical? Would it provide any real anonymity?
-----------------

Proposal: PreTunneling

The protocol is not really premix routing, because it lacks onion encryption 
and source routing. So an adversary would directly route requests to his 
siblings.
On the other hand the adversary does not get any advantage by pretending to be 
many nodes.
There is no defined anonymity set. However the protocol still makes 
correlation attacks a lot harder.

The tunnels are bidirectional and end-to-end encrypted to some other node. 
Messages are
authenticated in every node by a public key. Both ends use the same private 
key.

1) Node Alice wants to set up a tunnel to some unknown node that will be named 
Bob. In order to send a secret to him, she creates two requests that reveal 
it, when they are combined. She sends both to the same random destination.

The two requests are called tunnel request and decryption request. The route 
of the tunnel request will determine the route of the tunnel. Alice simply 
routes the tunnel request to an appropriate neighbour, as if she were just 
propagating it. The decryption request is send to some other neighbour or 
better through an existing tunnel, if available.

The protocol forbids sending tunnel requests through tunnels, because they 
would either lead to longer and longer tunnels or provide an adversary with 
short-cuts to the decryption request path.

2) Eventually both requests meet in one or two nodes. If there are two, then 
the one upstream on the
tunnel request path will win. Or if they are on different branches, then the 
one that first reaches their
common root will win.

For better security the first few nodes on the decryption request path should 
reject a corresponding tunnel request pretending that they detected a loop in 
the tunnel request
path.

Alice probably wants the final tunnel to be shorter by a certain number of 
nodes, in order to decrease latency, make the tunnel more reliable and reduce 
overhead for the network. This instruction is found in her secret message. 
The node that is reached by propagating the message upstream is named Bob.
(If the number that Alice has chosen is too large, then she will receive her 
own message and the tunnel set-up fails.)

3) Alices message is also part of a Diffie-Hellman key exchange. Bob completes 
it. He uses the new secret key
for generating an asymmetric key pair. The asymmetric cipher just has to be 
hard enough not be broken during the life time of the tunnel.

Bob sends the public key and his part of the DH key exchange to Alice. He 
authenticates his message to Alice using the old secret key from Alices 
message.

The nodes in the tunnel save the public key in order to authenticate later 
messages. Other upstream messages are accepted by nodes after they have seen 
the first valid downstream message.

Authentication on every node is necessary in order to prevent a malicious 
tunnel node from inserting fake messages for traffic analysis.

3) Alice verifies Bobs messages and generates the new symetric key. She also 
uses it for generating the common private key.

4) Alice can send local requests (and maybe remote decryption requests) 
through the encrypted tunnel, and Bob will send back the results. The nodes 
in the tunnel prevent replay attacks.

Alice should try to route local requests to their closest tunnel as often as 
possible. However she must make sure that she does not become vulnerable to 
correlation attacks using traffic analysis of her tunnels.
-------------- 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/20070518/7b3a28de/attachment.pgp 

From toad at amphibian.dyndns.org  Fri May 18 17:24:44 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Fri, 18 May 2007 18:24:44 +0100
Subject: [freenet-dev] Positive feedback for once
Message-ID: <200705181824.44962.toad@amphibian.dyndns.org>

An interesting IRC log...

[00:04] <haypo> no fuzzing. i just want to try freenet
[00:04] <haypo> it's a little bit faster than two years ago
[00:41] <toad_> <haypo> it's a little bit faster than two years ago
[00:41] <toad_> woooh!
[00:41] <toad_> :)
[00:53] <Kiit> toad_, good work, btw. Things seem to be much more smooth and 
fast than they were last time I tried freenet.
[00:53] <toad_> Kiit: two people telling me things have improved in an hour? 
there's something going on here... you must be an impostor!
[00:54] <Kiit> I've actually been able to download things within a few hours 
of starting up my node.
[00:54] <toad_> thanks anyway :)
[00:54] <toad_> Kiit: did you ever use 0.5?
[00:54] * Kiit goes off to donate some money.
[00:54] <Kiit> Yes
[00:54] <toad_> Kiit: it had a long "assimilation" period...
[00:54] <Kiit> Quite.
[00:54] <toad_> Kiit: you have darknet peers? or #freenet-refs refs?
[00:55] <Kiit> #freenet-refs so far, afaik.
[00:55] <toad_> if you happen to know a few people who are well established, 
that will help a lot
[00:55] <toad_> really? and it's still faster than 0.5? cool
[00:55] <Kiit> I expect so. I'm planning on exchanging refs over frost in a 
bit.
[00:55] <Kiit> Well, 0.5 varied alot speedwise for me.
[00:56] <toad_> 0.7 will too, it depends on the file
[00:56] <cbrannon> toad_: that was my experience too.  I was downloading with 
reasonable speed, as soon as I got a few peers.  Much more quickly than 0.5.
[00:56] <toad_> cbrannon: yeah...
[00:56] <Kiit> There were a few versions that I could pull things quicker than 
what I'm experiencing at the moment, but overall, it was slower and less 
reliable than right now.
[00:57] <toad_> cbrannon: opennet may well be better than 0.5's opennet was in 
terms of assimilation speed... but it's probably necessary for other reasons 
(network topology issues)
[00:57] * toad_ will post this conversation to devl :)
[00:59] <Kiit> Granted, this is all subjective.... :)
[01:00] <toad_> yeah, it's certainly true that if you know several folk 
already on freenet you can get a fast and secure connection quickly
[01:00] <toad_> the problem is 99% of our new users come from slashdot etc
[01:00] <toad_> and don't know anyone on freenet
[01:01] <toad_> organic growth doesn't happen enough to offset the 80% of 
users who come, find that they have to use IRC to get refs, conclude that it 
is both too much hassle and insecure, and go away
[01:01] <toad_> of course they're right about it being insecure...
[01:02] <cbrannon> The refbots were pretty good.  There were at least 3 in 
#freenet-refs when I started, so getting onto the network was fairly trivial.
[01:02] <toad_> hmmm interesting
[01:03] <cbrannon> It's just not hard to type "/msg refbot addref blabla"
[01:03] <toad_> true
[01:03] <toad_> but you have to register first
[01:03] <toad_> with nickserv
[01:03] <toad_> 99% of people don't know and won't do it even if they do know
[01:03] <toad_> for much the same reason: it is intuitively insecure
[01:04] <cbrannon> My policy was to add many peers quickly.  Security in 
numbers?
[01:05] <toad_> not really
[01:05] <Kiit> It would be interesting to modify the refbots so that they used 
#freenet-refs to grab "tier 2" peers and then when one had enough, use frost 
w/ encryption to get "tier 1" peers.
[01:05] <toad_> but there is speed in numbers :)
[01:05] <toad_> tier 2?
[01:06] <Kiit> tier 2 being arguably less secure irc-obtained auto-peers
[01:07] <cbrannon> Heh, can you really ever trust an opennet at all, anyway?
[01:07] <Kiit> this is based on the document "How to exchange node refs more 
securely" @ 
http://127.0.0.1:8888/USK at 8b7wZHMx1ACXjVRRc00RigvNpCGKN3atbtcPb5rlksY,~HFub4S23G5GYltu53XRexzbos7vLX7tG0GxjRJmFKg,AQACAAE/refXchgHOWTO/2/
[01:07] <cbrannon> Because somewhere, you need a central server, don't you?  
And that server could be attacked.
[01:08] <toad_> cbrannon: can you trust #freenet-refs?
[01:08] <toad_> there is a central server (network)
[01:09] <cbrannon> toad_: nope.
[01:09] <toad_> *.freenode.net
[01:10] <cbrannon> That's true.  You really can't trust anyone that you don't 
know offline
-------------- 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/20070518/fd15ceb4/attachment.pgp 

From jarvil at gmail.com  Sun May 20 12:19:21 2007
From: jarvil at gmail.com (jarvil at gmail.com)
Date: Sun, 20 May 2007 22:19:21 +1000
Subject: [freenet-dev] High Speed Links
Message-ID: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>

Hello,

I proposed an advanced option on the peers (friends) page for high speed links.

In the present code, if you increase the outgoing bandwith the peers
inevitably end up in backed off mode as the ones who cannot deal with
the higher throughput backoff the incoming connection. I dont know the
method used for Backed Off values but some basic math tells me that
mode nodes can only receive 10K/s for each connection. Let me explain.

If you have one node on default setting of 15K/s outgoing bandwith and
60K/s incoming (4xoutgoing). If a user has 6 connections you have a
max of 10K incoming for each connection. 10K/s is double the speed of
a modem connection and hardly broadband speed.  IMHO This severely
limits the speed of freenet.

What I would like to see is the ability to set individual bandwith on
peers OR designate a peer as high speed which excludes it from the
bandwith management on the normal peers. This would send a message to
the other peer requesting a high speed link which would appear on
their peer listing as request for high speed and the speed requested.
If they agree then the link operates at the new speed sending data at
the maximum speed specified until there is no more data to send.

Regards

Jarvil


From Volodya at WhenGendarmeSleeps.org  Mon May 21 10:16:13 2007
From: Volodya at WhenGendarmeSleeps.org (Volodya)
Date: Mon, 21 May 2007 11:16:13 +0100
Subject: [freenet-dev] High Speed Links
In-Reply-To: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
Message-ID: <4651716D.7010808@WhenGendarmeSleeps.org>

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

jarvil at gmail.com wrote:
> Hello,
> 
> I proposed an advanced option on the peers (friends) page for high speed links.
> 
> In the present code, if you increase the outgoing bandwith the peers
> inevitably end up in backed off mode as the ones who cannot deal with
> the higher throughput backoff the incoming connection. I dont know the
> method used for Backed Off values but some basic math tells me that
> mode nodes can only receive 10K/s for each connection. Let me explain.
> 
> If you have one node on default setting of 15K/s outgoing bandwith and
> 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
> max of 10K incoming for each connection. 10K/s is double the speed of
> a modem connection and hardly broadband speed.  IMHO This severely
> limits the speed of freenet.
> 
> What I would like to see is the ability to set individual bandwith on
> peers OR designate a peer as high speed which excludes it from the
> bandwith management on the normal peers. This would send a message to
> the other peer requesting a high speed link which would appear on
> their peer listing as request for high speed and the speed requested.
> If they agree then the link operates at the new speed sending data at
> the maximum speed specified until there is no more data to send.
> 
> Regards
> 
> Jarvil

This will also help those of us who are running more than one node and they are on the
same LAN.

- --
http://freedom.libsyn.com/       Voice of Freedom, Radical Podcast
http://freeselfdefence.info/     Self-defence wiki
http://www.kingstonstudents.org/ Kingston University students' forum

 "None of us are free until all of us are free."    ~ Mihail Bakunin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFGUXFsuWy2EFICg+0RAjpfAJ99QaV/EtJzUErEFa6MsmorEGKUDgCfTEgl
DroUyJIynDeP4BhmHZPN1xI=
=Ci/3
-----END PGP SIGNATURE-----


From nextgens at freenetproject.org  Mon May 21 10:25:35 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Mon, 21 May 2007 12:25:35 +0200
Subject: [freenet-dev] High Speed Links
In-Reply-To: <4651716D.7010808@WhenGendarmeSleeps.org>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<4651716D.7010808@WhenGendarmeSleeps.org>
Message-ID: <20070521102534.GB5623@freenetproject.org>

* Volodya <Volodya at WhenGendarmeSleeps.org> [2007-05-21 11:16:13]:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> jarvil at gmail.com wrote:
> > Hello,
> > 
> > I proposed an advanced option on the peers (friends) page for high speed links.
> > 
> > In the present code, if you increase the outgoing bandwith the peers
> > inevitably end up in backed off mode as the ones who cannot deal with
> > the higher throughput backoff the incoming connection. I dont know the
> > method used for Backed Off values but some basic math tells me that
> > mode nodes can only receive 10K/s for each connection. Let me explain.
> > 
> > If you have one node on default setting of 15K/s outgoing bandwith and
> > 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
> > max of 10K incoming for each connection. 10K/s is double the speed of
> > a modem connection and hardly broadband speed.  IMHO This severely
> > limits the speed of freenet.
> > 
> > What I would like to see is the ability to set individual bandwith on
> > peers OR designate a peer as high speed which excludes it from the
> > bandwith management on the normal peers. This would send a message to
> > the other peer requesting a high speed link which would appear on
> > their peer listing as request for high speed and the speed requested.
> > If they agree then the link operates at the new speed sending data at
> > the maximum speed specified until there is no more data to send.
> > 
> > Regards
> > 
> > Jarvil
> 
> This will also help those of us who are running more than one node and they are on the
> same LAN.
> 

I have tried to explain it on irc: it doesn't and won't help... and
probably will f*ck up the load-balancing.

Even if  we have "faster than  other" links, the node  doesn't take that
into account when it routes requests : the "fast link" isn't more likely
to be used than any other one  because of how routing works. We route to
what we  think to  be the  shortest path not  the local-fastest  one (to
avoid missrouting).

What would help is a way to "share" datastores amongst different trusted
nodes.

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/20070521/2644d7ec/attachment.pgp 

From freenet-devl at david.sowder.com  Mon May 21 15:43:33 2007
From: freenet-devl at david.sowder.com (David Sowder)
Date: Mon, 21 May 2007 10:43:33 -0500
Subject: [freenet-dev] High Speed Links
In-Reply-To: <20070521102534.GB5623@freenetproject.org>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>	<4651716D.7010808@WhenGendarmeSleeps.org>
	<20070521102534.GB5623@freenetproject.org>
Message-ID: <4651BE25.5040909@david.sowder.com>

Florent Daigni?re wrote:
> * Volodya <Volodya at WhenGendarmeSleeps.org> [2007-05-21 11:16:13]:
>
>   
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> jarvil at gmail.com wrote:
>>     
>>> Hello,
>>>
>>> I proposed an advanced option on the peers (friends) page for high speed links.
>>>
>>> In the present code, if you increase the outgoing bandwith the peers
>>> inevitably end up in backed off mode as the ones who cannot deal with
>>> the higher throughput backoff the incoming connection. I dont know the
>>> method used for Backed Off values but some basic math tells me that
>>> mode nodes can only receive 10K/s for each connection. Let me explain.
>>>
>>> If you have one node on default setting of 15K/s outgoing bandwith and
>>> 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
>>> max of 10K incoming for each connection. 10K/s is double the speed of
>>> a modem connection and hardly broadband speed.  IMHO This severely
>>> limits the speed of freenet.
>>>
>>> What I would like to see is the ability to set individual bandwith on
>>> peers OR designate a peer as high speed which excludes it from the
>>> bandwith management on the normal peers. This would send a message to
>>> the other peer requesting a high speed link which would appear on
>>> their peer listing as request for high speed and the speed requested.
>>> If they agree then the link operates at the new speed sending data at
>>> the maximum speed specified until there is no more data to send.
>>>
>>> Regards
>>>
>>> Jarvil
>>>       
>> This will also help those of us who are running more than one node and they are on the
>> same LAN.
>>
>>     
>
> I have tried to explain it on irc: it doesn't and won't help... and
> probably will f*ck up the load-balancing.
>
> Even if  we have "faster than  other" links, the node  doesn't take that
> into account when it routes requests : the "fast link" isn't more likely
> to be used than any other one  because of how routing works. We route to
> what we  think to  be the  shortest path not  the local-fastest  one (to
> avoid missrouting).
>
> What would help is a way to "share" datastores amongst different trusted
> nodes.
>   
I think sharing datastores could potentially be an interesting concept, 
but I'm not clear on the semantics.  This could potentially be rather 
easy to implement.

Does datastores include datacaches?
Are datastores only shared for requests and inserts act normally?
Would sharing for inserts make any sense since the shared nodes being 
peers would likely be close to each other location-wise anyway?
Would "chains" of trust be used in this sharing idea?  Would shared 
datastores be potentially implemented similar to how Squid caches 
communicate?



From edt at aei.ca  Mon May 21 16:45:21 2007
From: edt at aei.ca (Ed Tomlinson)
Date: Mon, 21 May 2007 12:45:21 -0400
Subject: [freenet-dev] High Speed Links
In-Reply-To: <20070521102534.GB5623@freenetproject.org>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<4651716D.7010808@WhenGendarmeSleeps.org>
	<20070521102534.GB5623@freenetproject.org>
Message-ID: <200705211245.21608.edt@aei.ca>

On Monday 21 May 2007 06:25, Florent Daigni?re wrote:
> * Volodya <Volodya at WhenGendarmeSleeps.org> [2007-05-21 11:16:13]:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > jarvil at gmail.com wrote:
> > > Hello,
> > > 
> > > I proposed an advanced option on the peers (friends) page for high speed links.
> > > 
> > > In the present code, if you increase the outgoing bandwith the peers
> > > inevitably end up in backed off mode as the ones who cannot deal with
> > > the higher throughput backoff the incoming connection. I dont know the
> > > method used for Backed Off values but some basic math tells me that
> > > mode nodes can only receive 10K/s for each connection. Let me explain.
> > > 
> > > If you have one node on default setting of 15K/s outgoing bandwith and
> > > 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
> > > max of 10K incoming for each connection. 10K/s is double the speed of
> > > a modem connection and hardly broadband speed.  IMHO This severely
> > > limits the speed of freenet.
> > > 
> > > What I would like to see is the ability to set individual bandwith on
> > > peers OR designate a peer as high speed which excludes it from the
> > > bandwith management on the normal peers. This would send a message to
> > > the other peer requesting a high speed link which would appear on
> > > their peer listing as request for high speed and the speed requested.
> > > If they agree then the link operates at the new speed sending data at
> > > the maximum speed specified until there is no more data to send.
> > > 
> > > Regards
> > > 
> > > Jarvil
> > 
> > This will also help those of us who are running more than one node and they are on the
> > same LAN.
> > 
> 
> I have tried to explain it on irc: it doesn't and won't help... and
> probably will f*ck up the load-balancing.
> 
> Even if  we have "faster than  other" links, the node  doesn't take that
> into account when it routes requests : the "fast link" isn't more likely
> to be used than any other one  because of how routing works. We route to
> what we  think to  be the  shortest path not  the local-fastest  one (to
> avoid missrouting)

This is not strictly true.  We try to use the best route.  If it happens to be
backed off we skip it unless all nodes are backed off.  If a link is faster
it should be backed off less...  If the nodes have agreed on a faster link,
load balancing should be able to take it into account.

> What would help is a way to "share" datastores amongst different trusted
> nodes.
> 
> NextGen$
> 


From toad at amphibian.dyndns.org  Mon May 21 19:45:59 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 21 May 2007 20:45:59 +0100
Subject: [freenet-dev] High Speed Links
In-Reply-To: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
Message-ID: <200705212046.00134.toad@amphibian.dyndns.org>

What you propose is a workaround for the fact that the current load balancing 
sucks, which would only be of value to nodes which have exceptionally fast 
internet connections. It is therefore not of any importance IMHO.

On Sunday 20 May 2007 13:19, jarvil at gmail.com wrote:
> Hello,
>
> I proposed an advanced option on the peers (friends) page for high speed
> links.
>
> In the present code, if you increase the outgoing bandwith the peers
> inevitably end up in backed off mode as the ones who cannot deal with
> the higher throughput backoff the incoming connection. I dont know the
> method used for Backed Off values but some basic math tells me that
> mode nodes can only receive 10K/s for each connection. Let me explain.
>
> If you have one node on default setting of 15K/s outgoing bandwith and
> 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
> max of 10K incoming for each connection. 10K/s is double the speed of
> a modem connection and hardly broadband speed.  IMHO This severely
> limits the speed of freenet.
>
> What I would like to see is the ability to set individual bandwith on
> peers OR designate a peer as high speed which excludes it from the
> bandwith management on the normal peers. This would send a message to
> the other peer requesting a high speed link which would appear on
> their peer listing as request for high speed and the speed requested.
> If they agree then the link operates at the new speed sending data at
> the maximum speed specified until there is no more data to send.
>
> Regards
>
> Jarvil
> _______________________________________________
> 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/20070521/9687a400/attachment.pgp 

From toad at amphibian.dyndns.org  Mon May 21 20:08:49 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 21 May 2007 21:08:49 +0100
Subject: [freenet-dev] [freenet-cvs] r13285 - in
	trunk/freenet/src/freenet: client/async l10n node
In-Reply-To: <20070520215109.EB9E33882E1@emu.freenetproject.org>
References: <20070520215109.EB9E33882E1@emu.freenetproject.org>
Message-ID: <200705212108.49629.toad@amphibian.dyndns.org>

Static is bad except for stuff that really is universal like Logger. Is this 
necessary? I suppose it's client layer so it doesn't matter that much... the 
basic issue is that we want to be able to run multiple nodes in one VM, at 
least for simulations.

On Sunday 20 May 2007 22:51, you wrote:
> Author: juiceman
> Date: 2007-05-20 21:51:09 +0000 (Sun, 20 May 2007)
> New Revision: 13285
>
> Modified:
>    trunk/freenet/src/freenet/client/async/USKManager.java
>    trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
>    trunk/freenet/src/freenet/node/NodeClientCore.java
> Log:
> Implement a config option for USKFetchers.  Resolves a //Fixme
>
> Modified: trunk/freenet/src/freenet/client/async/USKManager.java
> ===================================================================
> --- trunk/freenet/src/freenet/client/async/USKManager.java	2007-05-20
> 21:44:34 UTC (rev 13284) +++
> trunk/freenet/src/freenet/client/async/USKManager.java	2007-05-20 21:51:09
> UTC (rev 13285) @@ -32,8 +32,6 @@
>  	/** Backgrounded USKFetchers by USK. */
>  	final HashMap backgroundFetchersByClearUSK;
>
> -	// FIXME make this configurable
> -	static final int MAX_BACKGROUND_FETCHERS = 64;
>  	final LRUQueue temporaryBackgroundFetchersLRU;
>
>  	/** USKChecker's by USK. Deleted immediately on completion. */
> @@ -103,7 +101,7 @@
>  				backgroundFetchersByClearUSK.put(clear, f);
>  			}
>  			temporaryBackgroundFetchersLRU.push(clear);
> -			while(temporaryBackgroundFetchersLRU.size() > MAX_BACKGROUND_FETCHERS)
> { +			while(temporaryBackgroundFetchersLRU.size() >
> NodeClientCore.maxBackgroundUSKFetchers) { USK del = (USK)
> temporaryBackgroundFetchersLRU.pop();
>  				USKFetcher fetcher = (USKFetcher)
> backgroundFetchersByClearUSK.get(del.clearCopy());
> if(!fetcher.hasSubscribers()) {
>
> Modified: trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties
> ===================================================================
> --- trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties	2007-05-20
> 21:44:34 UTC (rev 13284) +++
> trunk/freenet/src/freenet/l10n/freenet.l10n.en.properties	2007-05-20
> 21:51:09 UTC (rev 13285) @@ -493,6 +493,8 @@
>  NodeClientCore.ignoreTooManyPathComponentsLong=If true, the node won't
> generate TOO_MANY_PATH_COMPONENTS errors when a URI is fed to it which has
> extra, meaningless subdirs (/blah/blah) on the end beyond what is needed to
> fetch the key (for example, old CHKs will often have filenames stuck on the
> end which weren't part of the original insert; this is obsolete because we
> can now include the filename, and it is confusing to be able to add
> arbitrary strings to a URI, and it makes them hard to compare). Only enable
> this option if you need it for compatibility with older apps; it will be
> removed soon. NodeClientCore.lazyResume=Complete loading of persistent
> requests after startup? (Uses more memory)
> NodeClientCore.lazyResumeLong=The node can load persistent queued requests
> during startup, or it can read the data into memory and then complete the
> request resuming process after the node has started up. Shorter start-up
> times, but uses more memory. +NodeClientCore.maxUSKFetchers=Maximum number
> of allowed USK fetchers +NodeClientCore.maxUSKFetchersLong=Maximum number
> of allowed USK fetchers
> NodeClientCore.movingTempDirOnTheFlyNotSupported=Moving temp directory on
> the fly not supported at present
> NodeClientCore.persistentTempDir=Persistent temp files directory
>  NodeClientCore.persistentTempDirLong=Name of directory to put persistent
> temp files in
>
> Modified: trunk/freenet/src/freenet/node/NodeClientCore.java
> ===================================================================
> --- trunk/freenet/src/freenet/node/NodeClientCore.java	2007-05-20 21:44:34
> UTC (rev 13284) +++
> trunk/freenet/src/freenet/node/NodeClientCore.java	2007-05-20 21:51:09 UTC
> (rev 13285) @@ -47,6 +47,7 @@
>  import freenet.support.Logger;
>  import freenet.support.SimpleFieldSet;
>  import freenet.support.api.BooleanCallback;
> +import freenet.support.api.IntCallback;
>  import freenet.support.api.BucketFactory;
>  import freenet.support.api.StringArrCallback;
>  import freenet.support.api.StringCallback;
> @@ -102,6 +103,8 @@
>  	private boolean lazyResume;
>  	protected final Persister persister;
>
> +	public static int maxBackgroundUSKFetchers;
> +
>  	// Client stuff that needs to be configged - FIXME
>  	static final int MAX_ARCHIVE_HANDLERS = 200; // don't take up much RAM...
> FIXME static final long MAX_CACHED_ARCHIVE_DATA = 32*1024*1024; // make a
> fixed fraction of the store by default? FIXME @@ -308,6 +311,21 @@
>
>  		lazyResume = nodeConfig.getBoolean("lazyResume");
>
> +		nodeConfig.register("maxBackgroundUSKFetchers", "64", sortOrder++, true,
> false, "NodeClientCore.maxUSKFetchers",
> +				"NodeClientCore.maxUSKFetchersLong", new IntCallback() {
> +					public int get() {
> +						return maxBackgroundUSKFetchers;
> +					}
> +					public void set(int uskFetch) throws InvalidConfigValueException {
> +						if(uskFetch <= 0) throw new
> InvalidConfigValueException(l10n("uskFetchersMustBeGreaterThanZero"));
> +							maxBackgroundUSKFetchers = uskFetch;
> +						}
> +					}
> +		);
> +
> +		maxBackgroundUSKFetchers =
> nodeConfig.getInt("maxBackgroundUSKFetchers"); +
> +
>  		// FIXME remove and remove related code when we can just block them.
>  		// REDFLAG normally we wouldn't use static variables to carry important
> non-final data, but in this // case it's temporary code which will be
> removed before 0.7.0. @@ -1013,6 +1031,10 @@
>  		return new GenericReadFilterCallback(uri, cb);
>  	}
>
> +	public int maxBackgroundUSKFetchers() {
> +		return maxBackgroundUSKFetchers;
> +	}
> +
>  	public boolean lazyResume() {
>  		return lazyResume;
>  	}
>
> _______________________________________________
> 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/20070521/2165311d/attachment.pgp 

From toad at amphibian.dyndns.org  Mon May 21 20:11:22 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 21 May 2007 21:11:22 +0100
Subject: [freenet-dev] High Speed Links
In-Reply-To: <200705212046.00134.toad@amphibian.dyndns.org>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<200705212046.00134.toad@amphibian.dyndns.org>
Message-ID: <200705212111.23513.toad@amphibian.dyndns.org>

On Monday 21 May 2007 20:45, Matthew Toseland wrote:
> What you propose is a workaround for the fact that the current load
> balancing sucks, which would only be of value to nodes which have
> exceptionally fast internet connections. It is therefore not of any
> importance IMHO.

Obviously the real solution is to fix load balancing/limiting. I'm not sure 
that will happen before 0.7.0 though, the current load code seems to more or 
less work.
>
> On Sunday 20 May 2007 13:19, jarvil at gmail.com wrote:
> > Hello,
> >
> > I proposed an advanced option on the peers (friends) page for high speed
> > links.
> >
> > In the present code, if you increase the outgoing bandwith the peers
> > inevitably end up in backed off mode as the ones who cannot deal with
> > the higher throughput backoff the incoming connection. I dont know the
> > method used for Backed Off values but some basic math tells me that
> > mode nodes can only receive 10K/s for each connection. Let me explain.
> >
> > If you have one node on default setting of 15K/s outgoing bandwith and
> > 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
> > max of 10K incoming for each connection. 10K/s is double the speed of
> > a modem connection and hardly broadband speed.  IMHO This severely
> > limits the speed of freenet.
> >
> > What I would like to see is the ability to set individual bandwith on
> > peers OR designate a peer as high speed which excludes it from the
> > bandwith management on the normal peers. This would send a message to
> > the other peer requesting a high speed link which would appear on
> > their peer listing as request for high speed and the speed requested.
> > If they agree then the link operates at the new speed sending data at
> > the maximum speed specified until there is no more data to send.
> >
> > Regards
> >
> > Jarvil
> > _______________________________________________
> > 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/20070521/26bb212c/attachment.pgp 

From jarvil at gmail.com  Mon May 21 22:27:22 2007
From: jarvil at gmail.com (jarvil at gmail.com)
Date: Tue, 22 May 2007 08:27:22 +1000
Subject: [freenet-dev] High Speed Links
In-Reply-To: <200705212046.00134.toad@amphibian.dyndns.org>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<200705212046.00134.toad@amphibian.dyndns.org>
Message-ID: <a940d48f0705211527u500dad32l82ed6aff0cace36@mail.gmail.com>

On 5/22/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> What you propose is a workaround for the fact that the current load balancing
> sucks, which would only be of value to nodes which have exceptionally fast
> internet connections. It is therefore not of any importance IMHO.
>

That was the whole point, to allow those with faster connections to be
able to use them. Eg the 1Mb connection I could use to setup a fast
link in agreement with another peer. But nexgens tell's me this wont
help because of the way the code works. I admit I am biased because my
propagation seems woefully slow as I dont have any darknet links (only
freenet links) yet. I wanted to compensate for this by setting up
faster links with someone on the darknet to assist in propagating data
but I am told it wont help. Its frustrating though when you have
10Mbit down, 1Mbit up and you are transmitting into freenet at 10K/s.

Jarvil aka rtfmoz


From nextgens at freenetproject.org  Mon May 21 22:44:05 2007
From: nextgens at freenetproject.org (Florent =?iso-8859-1?Q?Daigni=E8re?=)
Date: Tue, 22 May 2007 00:44:05 +0200
Subject: [freenet-dev] High Speed Links
In-Reply-To: <200705211245.21608.edt@aei.ca>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<4651716D.7010808@WhenGendarmeSleeps.org>
	<20070521102534.GB5623@freenetproject.org>
	<200705211245.21608.edt@aei.ca>
Message-ID: <20070521224404.GD5539@freenetproject.org>

* Ed Tomlinson <edt at aei.ca> [2007-05-21 12:45:21]:

> On Monday 21 May 2007 06:25, Florent Daigni?re wrote:
> > * Volodya <Volodya at WhenGendarmeSleeps.org> [2007-05-21 11:16:13]:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > jarvil at gmail.com wrote:
> > > > Hello,
> > > > 
> > > > I proposed an advanced option on the peers (friends) page for high speed links.
> > > > 
> > > > In the present code, if you increase the outgoing bandwith the peers
> > > > inevitably end up in backed off mode as the ones who cannot deal with
> > > > the higher throughput backoff the incoming connection. I dont know the
> > > > method used for Backed Off values but some basic math tells me that
> > > > mode nodes can only receive 10K/s for each connection. Let me explain.
> > > > 
> > > > If you have one node on default setting of 15K/s outgoing bandwith and
> > > > 60K/s incoming (4xoutgoing). If a user has 6 connections you have a
> > > > max of 10K incoming for each connection. 10K/s is double the speed of
> > > > a modem connection and hardly broadband speed.  IMHO This severely
> > > > limits the speed of freenet.
> > > > 
> > > > What I would like to see is the ability to set individual bandwith on
> > > > peers OR designate a peer as high speed which excludes it from the
> > > > bandwith management on the normal peers. This would send a message to
> > > > the other peer requesting a high speed link which would appear on
> > > > their peer listing as request for high speed and the speed requested.
> > > > If they agree then the link operates at the new speed sending data at
> > > > the maximum speed specified until there is no more data to send.
> > > > 
> > > > Regards
> > > > 
> > > > Jarvil
> > > 
> > > This will also help those of us who are running more than one node and they are on the
> > > same LAN.
> > > 
> > 
> > I have tried to explain it on irc: it doesn't and won't help... and
> > probably will f*ck up the load-balancing.
> > 
> > Even if  we have "faster than  other" links, the node  doesn't take that
> > into account when it routes requests : the "fast link" isn't more likely
> > to be used than any other one  because of how routing works. We route to
> > what we  think to  be the  shortest path not  the local-fastest  one (to
> > avoid missrouting)
> 
> This is not strictly true.  We try to use the best route.  If it happens to be
> backed off we skip it unless all nodes are backed off.  If a link is faster
> it should be backed off less...  If the nodes have agreed on a faster link,
> load balancing should be able to take it into account.

Backoff  isn't  triggered by  bandwidth  shortage  directly :  bandwidth
shortage causes rejections and rejections cause backoff to be triggered.

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/20070522/e19a643a/attachment.pgp 

From toad at amphibian.dyndns.org  Mon May 21 22:34:12 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Mon, 21 May 2007 23:34:12 +0100
Subject: [freenet-dev] High Speed Links
In-Reply-To: <a940d48f0705211527u500dad32l82ed6aff0cace36@mail.gmail.com>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<200705212046.00134.toad@amphibian.dyndns.org>
	<a940d48f0705211527u500dad32l82ed6aff0cace36@mail.gmail.com>
Message-ID: <200705212334.19325.toad@amphibian.dyndns.org>

On Monday 21 May 2007 23:27, jarvil at gmail.com wrote:
> On 5/22/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > What you propose is a workaround for the fact that the current load
> > balancing sucks, which would only be of value to nodes which have
> > exceptionally fast internet connections. It is therefore not of any
> > importance IMHO.
>
> That was the whole point, to allow those with faster connections to be
> able to use them. Eg the 1Mb connection I could use to setup a fast
> link in agreement with another peer. But nexgens tell's me this wont
> help because of the way the code works. I admit I am biased because my
> propagation seems woefully slow as I dont have any darknet links (only
> freenet links) yet. I wanted to compensate for this by setting up
> faster links with someone on the darknet to assist in propagating data
> but I am told it wont help. Its frustrating though when you have
> 10Mbit down, 1Mbit up and you are transmitting into freenet at 10K/s.

Well do we really want nodes to be sending 99% of their traffic to a single 
ubernode? That doesn't seem healthy to me. Potential attacks.
-------------- 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/20070521/e1adb935/attachment.pgp 

From jarvil at gmail.com  Tue May 22 00:15:30 2007
From: jarvil at gmail.com (jarvil at gmail.com)
Date: Tue, 22 May 2007 10:15:30 +1000
Subject: [freenet-dev] High Speed Links
In-Reply-To: <200705212334.19325.toad@amphibian.dyndns.org>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<200705212046.00134.toad@amphibian.dyndns.org>
	<a940d48f0705211527u500dad32l82ed6aff0cace36@mail.gmail.com>
	<200705212334.19325.toad@amphibian.dyndns.org>
Message-ID: <a940d48f0705211715p20901ed8p2f2ca95c17ba361b@mail.gmail.com>

>
> Well do we really want nodes to be sending 99% of their traffic to a single
> ubernode? That doesn't seem healthy to me. Potential attacks.
>

Since the links of this nature would be entirely random there is no
such thing as an "ubernode". The structure of freenet is such that
there is no way to map topology as you have said.

Regards

Jarvil


From juiceman69 at gmail.com  Tue May 22 01:55:23 2007
From: juiceman69 at gmail.com (Juiceman)
Date: Mon, 21 May 2007 21:55:23 -0400
Subject: [freenet-dev] [freenet-cvs] r13285 - in
	trunk/freenet/src/freenet: client/async l10n node
In-Reply-To: <200705212108.49629.toad@amphibian.dyndns.org>
References: <20070520215109.EB9E33882E1@emu.freenetproject.org>
	<200705212108.49629.toad@amphibian.dyndns.org>
Message-ID: <8b525dee0705211855k3768fb3bu395f0132a0c97b9e@mail.gmail.com>

Honestly, I don't know the difference.  I am learning Java through
experimentation and "static" was how I got rid of the compiler error.
How would I do this correctly?

On 5/21/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> Static is bad except for stuff that really is universal like Logger. Is this
> necessary? I suppose it's client layer so it doesn't matter that much... the
> basic issue is that we want to be able to run multiple nodes in one VM, at
> least for simulations.
>


From toad at amphibian.dyndns.org  Tue May 22 09:41:42 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 22 May 2007 10:41:42 +0100
Subject: [freenet-dev] High Speed Links
In-Reply-To: <a940d48f0705211715p20901ed8p2f2ca95c17ba361b@mail.gmail.com>
References: <a940d48f0705200519hc9579c0qadd8bb7e70dc7cda@mail.gmail.com>
	<200705212334.19325.toad@amphibian.dyndns.org>
	<a940d48f0705211715p20901ed8p2f2ca95c17ba361b@mail.gmail.com>
Message-ID: <200705221041.50024.toad@amphibian.dyndns.org>

On Tuesday 22 May 2007 01:15, jarvil at gmail.com wrote:
> > Well do we really want nodes to be sending 99% of their traffic to a
> > single ubernode? That doesn't seem healthy to me. Potential attacks.
>
> Since the links of this nature would be entirely random there is no
> such thing as an "ubernode". The structure of freenet is such that
> there is no way to map topology as you have said.

I mean on the level of an individual node.
-------------- 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/20070522/d5964818/attachment.pgp 

From toad at amphibian.dyndns.org  Tue May 22 14:20:12 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 22 May 2007 15:20:12 +0100
Subject: [freenet-dev] [freenet-cvs] r13285 - in
	trunk/freenet/src/freenet: client/async l10n node
In-Reply-To: <8b525dee0705211855k3768fb3bu395f0132a0c97b9e@mail.gmail.com>
References: <20070520215109.EB9E33882E1@emu.freenetproject.org>
	<200705212108.49629.toad@amphibian.dyndns.org>
	<8b525dee0705211855k3768fb3bu395f0132a0c97b9e@mail.gmail.com>
Message-ID: <200705221520.12386.toad@amphibian.dyndns.org>

On Tuesday 22 May 2007 02:55, Juiceman wrote:
> Honestly, I don't know the difference.  I am learning Java through
> experimentation and "static" was how I got rid of the compiler error.
> How would I do this correctly?

Static means it belongs to the class rather than the particular instance of 
the class. For example Logger provides a static interface because it's 
perfectly okay for all nodes etc in the same VM to use a single Logger. Most 
things should be kept on other structures. For example most of the client 
layer has access to an InsertContext or FetchContext.
>
> On 5/21/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> > Static is bad except for stuff that really is universal like Logger. Is
> > this necessary? I suppose it's client layer so it doesn't matter that
> > much... the basic issue is that we want to be able to run multiple nodes
> > in one VM, at least for simulations.



From toad at amphibian.dyndns.org  Tue May 22 15:29:55 2007
From: toad at amphibian.dyndns.org (Matthew Toseland)
Date: Tue, 22 May 2007 16:29:55 +0100
Subject: [freenet-dev] Freenet 0.7 build 1033
Message-ID: <200705221630.02252.toad@amphibian.dyndns.org>

Build 1033 is now available, please upgrade. This build includes a fix to a 
major routing bug, which caused the node to route all requests to a single 
node if all nodes are backed off. This probably caused problems with both 
load and routing. Therefore, this build will be mandatory on June 5th: If you 
don't update before then, your node won't be able to talk to 1033+ nodes. The 
build also includes various other fixes and improvements including work on 
the datastore, translations, probe requests, and FCP (queued inserts now show 
the public URI, not the private one). Tell me if the auto-update doesn't 
work. Please upgrade!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetp