Send Devl mailing list submissions to
devl at freenetproject.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.uprizer.com/mailman/listinfo/devl
or, via email, send a message with subject or body 'help' to
devl-request at freenetproject.org
You can reach the person managing the list at
devl-admin at freenetproject.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devl digest..."
Today's Topics:
1. Re: Aardvark (Peter Todd)
2. Re: Announcement Protocol (Oskar Sandberg)
3. Re: Aardvark (Oskar Sandberg)
4. Re: Aardvark (Chris Anderson)
5. Re: Killing Freenet (Re: [freenet-devl] Aardvark) (Oskar Sandberg)
6. Re: Aardvark (Peter Todd)
7. Re: Killing Freenet (Re: [freenet-devl] Aardvark) (Peter Todd)
8. Re: Aardvark (Oskar Sandberg)
9. Re: Killing Freenet (Re: [freenet-devl] Aardvark) (Oskar Sandberg)
10. Re: Killing Freenet (Re: [freenet-devl] Aardvark) (Sebastian Spaeth)
11. Re: Killing Freenet (Re: [freenet-devl] Aardvark) (Peter Todd)
12. Re: Announcement Protocol (Chris Anderson)
13. Re: Aardvark (Scott G. Miller)
--__--__--
Message: 1
From: Peter Todd <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Date: Sat, 3 Feb 2001 10:27:20 -0500
Reply-To: devl at freenetproject.org
On Sat, 03 Feb 2001, you wrote:
> > Your absolutely correct and are in fact backing up my position. I
> > was just clarifying the point, but I entirely agree. KSKs are bad.
> > *Baaaad*. When you're about to use a KSK, ask yourself three
> > questions:
> >
> > 1) Do I need a KSK?
> > 2) Really?
> > 3) Repeat question 1
>
> If KSK's are so evil as to give the impression that they are a stable
> way of adding content to freenet, why not change their behavior...
> Instead of propagating the old KSK value when a collision happens,
> propagate the new value. For example, if I insert my KSK at robots.txt,
> it will overwrite any robots.txt that already exists instead of
> propagating the existing one.
But then you would end up with people constantly trying to kill each
others KSK's. Not good.
--
retep at penguinpowered.com http://retep.tripod.com
--__--__--
Message: 2
Date: Sat, 3 Feb 2001 16:35:07 +0100
From: Oskar Sandberg <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org
On Sat, Feb 03, 2001 at 10:08:56AM -0500, Chris Anderson wrote:
> On Sat, 3 Feb 2001, Ruediger Kapitza wrote:
>
> > > On Fri, 2 Feb 2001, Scott G. Miller wrote:
> > >
> > > Thats not a good idea. You don't want any specific node to
> > > control the keyspace assigned to Alice. More importantly, the
> > > entire point is to create random links in the network when adding
> > > a new node. Simulations show this as increasing the reliability
> > > of Freenet routing by 20-30% over inform. Allowing Alice to
> > > choose nodes already close to her trusted friends would be equal
> > > or worse than inform.
>
> Hmm. The 20-30% number is interesting, how did you arrive at that?
Simulation.
> > Why should Bob control the keyspace if he gives me some some
> > addresses. I thought this depends on some random numbers of hashes
> > form all the nodes which are influenced by the announcement.
> >
> > The second point is true.
> >
> > This leaves still the point that Bob2 can choose the route if he
> > knowes some nodes which belong like him to an evil party. Is this
> > really a problem? Why not? What happens if Alice has 30 node
> > addresses and 29 are from some kind of evil party?
>
> I don't see the difference between Alice choosing the routes and
> Bob1..BobN choosing the routes. Anyway, can't Alice do this with the
> proposed protocol by setting the htl of the Announcement to 1 and
> messaging Bob2..BobN herself? It seems that this is a Freenet
> crawling protocol. I do thing that the inform mechanism is producing
> a loosely connected network and should be replaced.
Yes, but then each of the negotiations would result in a different initial
ref value for Alice, which is very different situation.
There are any number of things wrong with this suggestion:
1) In our version, Alice has to trust that Bob is a legitimate node, but Bob
does not even have to know who Alice is. Freenet nodes should (for obvious
reasons) not be handing out lists of their references to just anybody, so
for Bob to give Alice a bunch of references he has to have reason to trust
Alice - and not just to be a legitimate node, but to being somebody who is
capable of keeping this information secret (and either way, when Alice
proceeds to make the announcement there is a leak, at least to traffic
analysis, exactly what references Bob had). In general, anybody sending
out the contents of their routing table makes me worried, and even if one
doesn't care about that, the double trust makes introducing a new node a
lot more difficult.
2) If Alice gets her initial nodes from her friend Bob, and the then her
other friend Charles gets his initial nodes from her, all three friends
will start off with the same references in Freenet. This creates a
correlation between the trust connection between Alice, Bob, and Charles,
and their roles in Freenet - something that we are trying to avoid.
3) Alice's ability to pick an choose which nodes take part in the
negotiation troublesome, see above.
4) It undoes the important advantages to the routing.
Again i could probably go on if I spent more than 5 minutes thinking about
it, but I don't really see a reason.
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
md98-osa at nada.kth.se
--__--__--
Message: 3
Date: Sat, 3 Feb 2001 16:37:22 +0100
From: Oskar Sandberg <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Reply-To: devl at freenetproject.org
On Sat, Feb 03, 2001 at 10:27:20AM -0500, Peter Todd wrote:
> On Sat, 03 Feb 2001, you wrote:
< >
> > If KSK's are so evil as to give the impression that they are a stable
> > way of adding content to freenet, why not change their behavior...
> > Instead of propagating the old KSK value when a collision happens,
> > propagate the new value. For example, if I insert my KSK at robots.txt,
> > it will overwrite any robots.txt that already exists instead of
> > propagating the existing one.
>
> But then you would end up with people constantly trying to kill each
> others KSK's. Not good.
Well, it's a good way of getting rid of KSKs altogether should we want to,
although I would be rather unhappy about the other effects (the ability to
easily have several different version of one SVK or SSK document on the
the network).
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
md98-osa at nada.kth.se
--__--__--
Message: 4
Date: Sat, 3 Feb 2001 10:36:15 -0500 (EST)
From: Chris Anderson <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Reply-To: devl at freenetproject.org
On Sat, 03 Feb 2001, Peter Todd wrote:
> On Sat, 03 Feb 2001, you wrote:
>
> > > Your absolutely correct and are in fact backing up my position.
> > > I was just clarifying the point, but I entirely agree. KSKs are
> > > bad. *Baaaad*. When you're about to use a KSK, ask yourself
> > > three questions:
> > >
> > > 1) Do I need a KSK?
> > > 2) Really?
> > > 3) Repeat question 1
> >
> > If KSK's are so evil as to give the impression that they are a
> > stable way of adding content to freenet, why not change their
> > behavior... Instead of propagating the old KSK value when a
> > collision happens, propagate the new value. For example, if I
> > insert my KSK at robots.txt, it will overwrite any robots.txt that
> > already exists instead of propagating the existing one.
>
> But then you would end up with people constantly trying to kill
> each others KSK's. Not good.
If a node really wanted it's robots.txt to survive, it could refuse
the insert request.
--__--__--
Message: 5
Date: Sat, 3 Feb 2001 16:41:00 +0100
From: Oskar Sandberg <[email protected]>
To: devl at freenetproject.org
Subject: Re: Killing Freenet (Re: [freenet-devl] Aardvark)
Reply-To: devl at freenetproject.org
On Sat, Feb 03, 2001 at 09:47:50AM -0500, Peter Todd wrote:
> On Sat, 03 Feb 2001, you wrote:
< >
> > It would be interesting to see what the exception that causes the removal
> > is. Are we failing to connect (maybe we need to increase the connect
> > timeout, our arbitrary cutoff after 5 seconds when I believe the TCP says
> > two minutes is somewhat shaky), are we failing to get responses back
> > from nodes we send to, or is the authentication not working, or what?
>
> Is it actually 5 seconds? The default is 2000 miliseconds, 2 seconds
> right? Anyway I just set my timeout on my node to 5000 miliseconds to
> see what will happen.
static public final int defaultConnectTimeout = 30000;
So actually the default in 30 seconds...
> What can cause a TCP connect timeout anyway? Failure for the node at
> the other end to connect() the connection? In which case overloaded
> nodes will get connect timeouts while less used nodes won't?
If the other machine is simply not online, or not responding for some
reason.
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
md98-osa at nada.kth.se
--__--__--
Message: 6
From: Peter Todd <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Date: Sat, 3 Feb 2001 10:39:13 -0500
Reply-To: devl at freenetproject.org
On Sat, 03 Feb 2001, you wrote:
> > But then you would end up with people constantly trying to kill each
> > others KSK's. Not good.
>
> Well, it's a good way of getting rid of KSKs altogether should we want to,
> although I would be rather unhappy about the other effects (the ability to
> easily have several different version of one SVK or SSK document on the
> the network).
Much easier is to just give KSK's the same treatment we gave KHK's,
cacheable = no
Do this and we'll still have stupid users complaining that their
KSK's were overwritten for all eternity!
--
retep at penguinpowered.com http://retep.tripod.com
--__--__--
Message: 7
From: Peter Todd <[email protected]>
To: devl at freenetproject.org
Subject: Re: Killing Freenet (Re: [freenet-devl] Aardvark)
Date: Sat, 3 Feb 2001 10:41:43 -0500
Reply-To: devl at freenetproject.org
On Sat, 03 Feb 2001, you wrote:
> > Is it actually 5 seconds? The default is 2000 miliseconds, 2 seconds
> > right? Anyway I just set my timeout on my node to 5000 miliseconds to
> > see what will happen.
>
> static public final int defaultConnectTimeout = 30000;
>
> So actually the default in 30 seconds...
Doesn't that get set to the value of connectTimeout in .freenetrc?
The default, IE the value the .freenetrc in the tarball is set to,
connectTimeout there is 2000
> > What can cause a TCP connect timeout anyway? Failure for the node at
> > the other end to connect() the connection? In which case overloaded
> > nodes will get connect timeouts while less used nodes won't?
>
> If the other machine is simply not online, or not responding for some
> reason.
And one of those possibly reasons is being overloaded, (IE max
connectionTreads reached) correct?
If so having low connect timeouts is a good way for nodes to
automaticly reduce the load on nodes that are already overloaded to
the point where any request that does succeed should go through
relatively quickly. (< (2 * hopsneeded) sec)
Or am I missing something?
--
retep at penguinpowered.com http://retep.tripod.com
--__--__--
Message: 8
Date: Sat, 3 Feb 2001 16:50:25 +0100
From: Oskar Sandberg <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
Reply-To: devl at freenetproject.org
On Sat, Feb 03, 2001 at 10:39:13AM -0500, Peter Todd wrote:
> On Sat, 03 Feb 2001, you wrote:
> > > But then you would end up with people constantly trying to kill each
> > > others KSK's. Not good.
> >
> > Well, it's a good way of getting rid of KSKs altogether should we want to,
> > although I would be rather unhappy about the other effects (the ability to
> > easily have several different version of one SVK or SSK document on the
> > the network).
>
> Much easier is to just give KSK's the same treatment we gave KHK's,
> cacheable = no
>
> Do this and we'll still have stupid users complaining that their
> KSK's were overwritten for all eternity!
No, that doesn't help. A KSK is an SVK or SSK where the private key is
generated from a publicly know value. People could just as easily label
the data they are inserting under KSK today as being under SVK, the
network wouldn't know the difference. The only way to kill them is to make
it completely unpractical to have a publicly known private key - for
example allowing updates on all signed data...
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
md98-osa at nada.kth.se
--__--__--
Message: 9
Date: Sat, 3 Feb 2001 16:55:13 +0100
From: Oskar Sandberg <[email protected]>
To: devl at freenetproject.org
Subject: Re: Killing Freenet (Re: [freenet-devl] Aardvark)
Reply-To: devl at freenetproject.org
On Sat, Feb 03, 2001 at 10:41:43AM -0500, Peter Todd wrote:
> On Sat, 03 Feb 2001, you wrote:
> > > Is it actually 5 seconds? The default is 2000 miliseconds, 2 seconds
> > > right? Anyway I just set my timeout on my node to 5000 miliseconds to
> > > see what will happen.
> >
> > static public final int defaultConnectTimeout = 30000;
> >
> > So actually the default in 30 seconds...
>
> Doesn't that get set to the value of connectTimeout in .freenetrc?
> The default, IE the value the .freenetrc in the tarball is set to,
> connectTimeout there is 2000
Well, Setup.java says:
public static void setParamConnectTimeout() {
String id = "connectTimeout";
expComment("How long to wait to connect to a host before giving up
(in milliseconds)");
long l = params.getlong(id,Core.defaultConnectTimeout);
if (expert)
l = getNumber("?",l);
out.println(id+ "=" + l);
}
I'm assuming that the first time this is run the params object is empty...
> > > What can cause a TCP connect timeout anyway? Failure for the node at
> > > the other end to connect() the connection? In which case overloaded
> > > nodes will get connect timeouts while less used nodes won't?
> >
> > If the other machine is simply not online, or not responding for some
> > reason.
>
> And one of those possibly reasons is being overloaded, (IE max
> connectionTreads reached) correct?
No, such machines will currently just close the connection. This will
result in a SendFailedException on the first message.
> If so having low connect timeouts is a good way for nodes to
> automaticly reduce the load on nodes that are already overloaded to
> the point where any request that does succeed should go through
> relatively quickly. (< (2 * hopsneeded) sec)
>
> Or am I missing something?
In theory maybe, but in practice there are a lot more things then load
that will effect the time, and it could just be an internet quirk that it
takes longer than that to connect sometimes.
>
> --
> retep at penguinpowered.com http://retep.tripod.com
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://www.uprizer.com/mailman/listinfo/devl
--
'DeCSS would be fine. Where is it?'
'Here,' Montag touched his head.
'Ah,' Granger smiled and nodded.
Oskar Sandberg
md98-osa at nada.kth.se
--__--__--
Message: 10
Date: Sat, 03 Feb 2001 17:02:27 +0100
From: Sebastian Spaeth <[email protected]>
Organization: University of =?iso-8859-1?Q?Link=F6ping?=
To: devl at freenetproject.org
Subject: Re: Killing Freenet (Re: [freenet-devl] Aardvark)
Reply-To: devl at freenetproject.org
Oskar Sandberg wrote:
> > Doesn't that get set to the value of connectTimeout in .freenetrc?
> > The default, IE the value the .freenetrc in the tarball is set to,
> > connectTimeout there is 2000
>
> Well, Setup.java says:
>
> public static void setParamConnectTimeout() {
> String id = "connectTimeout";
> expComment("How long to wait to connect to a host before giving up
> (in milliseconds)");
> long l = params.getlong(id,Core.defaultConnectTimeout);
> if (expert)
> l = getNumber("?",l);
> out.println(id+ "=" + l);
> }
>
> I'm assuming that the first time this is run the params object is empty...
The Core.default value will only be used if the config file does not
exist yet. So if you are running this over a provided sample .freenetrc
it will use its values.
WindowsSetup dynamically creates the freenet.ini via Setup.java and uses
the Core.default values.
Sebastian
--__--__--
Message: 11
From: Peter Todd <[email protected]>
To: devl at freenetproject.org
Subject: Re: Killing Freenet (Re: [freenet-devl] Aardvark)
Date: Sat, 3 Feb 2001 10:55:58 -0500
Reply-To: devl at freenetproject.org
On Sat, 03 Feb 2001, you wrote:
> > > > Is it actually 5 seconds? The default is 2000 miliseconds, 2 seconds
> > > > right? Anyway I just set my timeout on my node to 5000 miliseconds to
> > > > see what will happen.
> > >
> > > static public final int defaultConnectTimeout = 30000;
> > >
> > > So actually the default in 30 seconds...
> >
> > Doesn't that get set to the value of connectTimeout in .freenetrc?
> > The default, IE the value the .freenetrc in the tarball is set to,
> > connectTimeout there is 2000
>
> Well, Setup.java says:
>
> public static void setParamConnectTimeout() {
> String id = "connectTimeout";
> expComment("How long to wait to connect to a host before giving up
> (in milliseconds)");
> long l = params.getlong(id,Core.defaultConnectTimeout);
> if (expert)
> l = getNumber("?",l);
> out.println(id+ "=" + l);
> }
>
> I'm assuming that the first time this is run the params object is empty...
Most Linux users probably don't use Setup.java I know I didn't say
anything about it's use in my Install and Admin artical.
If 30 seconds is the correct default we better make that the default
in .freenetrc
> > And one of those possibly reasons is being overloaded, (IE max
> > connectionTreads reached) correct?
>
> No, such machines will currently just close the connection. This will
> result in a SendFailedException on the first message.
Which will punish the node in the same way that any connection fail
will, removing references to it and reducing it's load as you know.
--
retep at penguinpowered.com http://retep.tripod.com
--__--__--
Message: 12
Date: Sat, 3 Feb 2001 11:10:20 -0500 (EST)
From: Chris Anderson <[email protected]>
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Announcement Protocol
Reply-To: devl at freenetproject.org
On Sat, Feb 03, 2001, Oskar Sandberg wrote:
>
> 1) In our version, Alice has to trust that Bob is a legitimate
> node, but Bob does not even have to know who Alice is. Freenet
> nodes should (for obvious reasons) not be handing out lists of
> their references to just anybody, so for Bob to give Alice a bunch
> of references he has to have reason to trust Alice - and not just
> to be a legitimate node, but to being somebody who is capable of
> keeping this information secret (and either way, when Alice
> proceeds to make the announcement there is a leak, at least to
> traffic analysis, exactly what references Bob had).
Am I misunderstanding? Isn't the purpose of the Announcement
protocol to seed Alice with references to other nodes, regardless of
Alice's evilness? How can you stop evil Alice from Announcing
to every new freenet node she finds, culling lots of references?
--__--__--
Message: 13
Date: Sat, 3 Feb 2001 11:34:28 -0500
To: devl at freenetproject.org
Subject: Re: [freenet-devl] Aardvark
From: "Scott G. Miller" <[email protected]>
Reply-To: devl at freenetproject.org
--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Feb 03, 2001 at 10:08:14AM -0500, Chris Anderson wrote:
> On Fri, 2 Feb 2001, Scott G. Miller wrote:
>=20
> > On Thu, Feb 01, 2001 at 05:29:11PM -0500, Peter Todd wrote:
> >
> > > And finally I've had one of my keys, KSK at robots.txt, overwritten
> > > by someone else. Though the key should soon drop out with the new
> > > special-case of robots.txt in fproxy.
> >
> > Your absolutely correct and are in fact backing up my position. I
> > was just clarifying the point, but I entirely agree. KSKs are bad.
> > *Baaaad*. When you're about to use a KSK, ask yourself three
> > questions:
> >
> > 1) Do I need a KSK?
> > 2) Really?
> > 3) Repeat question 1
>=20
> If KSK's are so evil as to give the impression that they are a stable
> way of adding content to freenet, why not change their behavior...
> Instead of propagating the old KSK value when a collision happens,
> propagate the new value. For example, if I insert my KSK at robots.txt,
> it will overwrite any robots.txt that already exists instead of
> propagating the existing one.
How the fuck would that help? Besides completely remove any smidgen of
usefulness they do have.
--sdtB3X0nJg68CQEu
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6fDMUr9IW4v3mHtQRAjv7AJ0QBKXPUwBcc76P3MOYwtRChy/4KgCfcFR7
oMlHK76RwUDodGpSJlclxUk=
=wrDE
-----END PGP SIGNATURE-----
--sdtB3X0nJg68CQEu--
--__--__--
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://www.uprizer.com/mailman/listinfo/devl
End of Devl Digest
