Re: [freenet-dev] Implemented random first hop
On Sunday 28 July 2002 21:11, Matthew wrote: CVS now is at version 489, and this includes code to always route to a random key on the first hop, at oskar's suggestion. This hopefully will have the following benefits: a) prevents the network from splitting, sows it back together when/if it does b) if you can't find a piece of data, then retry with a higher HTL, your request will be initially routed to a different node. So you have a good chance of finding the data, if it's anywhere reachable from any of your references, by repeatedly rerequesting with a slowly escalating HTL. Costs: a) increases average path length by 1 hop b) possible impact on specialization? c) random hop is probably not the most likely to find the data, so may d) result in lower performance/more DNFs... hopefully the positive impacts will overwhelm this. Good work. My intituition is that the benefits will outway the costs. Keep in mind that this is the third significant change that has happended recently, so it might be hard to judge whether it is working or not by looking at the performence of the public network. Other changes: 0) maxRoutingSteps increased 1) overload triaging turned off. --gj p.s. Announcing stuff on the mailing lists ahead of time never hurts. -- Freesite (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Implemented random first hop
On Mon, Jul 29, 2002 at 09:29:07AM -0400, Gianni Johansson wrote: On Sunday 28 July 2002 21:11, Matthew wrote: CVS now is at version 489, and this includes code to always route to a random key on the first hop, at oskar's suggestion. This hopefully will have the following benefits: a) prevents the network from splitting, sows it back together when/if it does b) if you can't find a piece of data, then retry with a higher HTL, your request will be initially routed to a different node. So you have a good chance of finding the data, if it's anywhere reachable from any of your references, by repeatedly rerequesting with a slowly escalating HTL. Costs: a) increases average path length by 1 hop b) possible impact on specialization? c) random hop is probably not the most likely to find the data, so may d) result in lower performance/more DNFs... hopefully the positive impacts will overwhelm this. Good work. My intituition is that the benefits will outway the costs. Have you seen significant evidence of splitting? What would you count as significant evidence of splitting? One node getting a whole site, and another getting a DNF at 25 htl? Can we extract something from the watchme database that would support the theory that freenet has splitting problems? Keep in mind that this is the third significant change that has happended recently, so it might be hard to judge whether it is working or not by looking at the performence of the public network. Other changes: 0) maxRoutingSteps increased 1) overload triaging turned off. --gj p.s. Announcing stuff on the mailing lists ahead of time never hurts. :) -- Freesite (0.4) freenet:SSK@npfV5XQijFkF6sXZvuO0o~kG4wEPAgM/homepage// msg03549/pgp0.pgp Description: PGP signature
[freenet-dev] Version 490; don't count routing steps pointing back to requestor
maxRoutingSteps should not include steps rejected because they point back to the requestor. Pro: Should prevent RouteNotFound, attempts were made to contact 0 nodes Con: Requests may get routed too far away from the ideal route. This is in the new build 490. Comments? Revocation notices? Flames (ian, that means you)? Death threats? Note to users: just because maxRoutingSteps=40 and HTL=15, does not mean that it should try to contact 15 nodes. Every time it gets a cleanly rejected (QueryRejected), the HTL is reduced by more than a factor of 2. msg03550/pgp0.pgp Description: PGP signature
Re: [freenet-dev] Implemented random first hop
I have seen a claim (on FMB) that one person can see more with build 489 than he could before. I've also seen claims that the noderefs that are available to a transient node behind a NAT firewall are different from the noderefs that are available to a non-transient node tunneling through a NAPT firewall. So, I *think* freenet is sort-of split by default. Hard to prove, though. I still think that some warning/discussion on the freenet-dev list was warranted, since I don't normally keep track of the #freenet irc channel. For instance, what network is #freenet on? Why isn't that on the freenetproject web site in an obvious place, such as the Developer area About This Site section, or the FAQ? I wouldn't even know that #freenet exists, apart from listening on the developer mailing list. ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Freenet distribution/seedNodes
On Fri, Jul 12, 2002 at 09:37:19AM +0200, Sebastian Spaeth wrote: Matthew Toseland schrieb: I want the installer to see it's in a directory with lib/freenet.jar, lib/freenet-ext.jar, and seednodes.ref, and then install using those rather than downloading. OK, let me summarize to see if I got it right. 1) The new behavior should occur with both the webinstaller and installers containing a specific snapshot 2) Befor using the local snapshot/downloading a new one we will see if lib/freenet.jar,... exists and use these instead. I see no problem at all for implementing this. The files we look for are only lib/freenet.jar,lib/freenet-ext.jar, and seednodes.ref, nothing else?! 3) Question: Should we delete lib/freenet.jar,... after we used them or should we leave them untouched ??? I'll leave that implementation detail to you. We've just unpacked the ZIP into a tempdir, then we install from the tempdir, the files will need to get deleted at some point... especially if we have a self extracting ZIP, but I don't know how to do that in java... maybe we could make a self extracting JAR installer, which would run when doubleclicked on a (windoze) system with java installed? Anyway, this is essential to improving routing and anonymity by reducing the number of nodes announcing to the centrally collected seedrefs... so if you could contact me, it would be helpful. Sebastian ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl msg03552/pgp0.pgp Description: PGP signature
Re: [freenet-dev] Version 490; don't count routing steps pointing back to requestor
On Mon, Jul 29, 2002 at 05:13:59PM +0100, Matthew Toseland wrote: maxRoutingSteps should not include steps rejected because they point back to the requestor. Pro: Should prevent RouteNotFound, attempts were made to contact 0 nodes Con: Requests may get routed too far away from the ideal route. This is in the new build 490. Comments? Revocation notices? Flames (ian, that means you)? Death threats? Looks ok, but I really think that we need to make it only do FSRR (First Step Random Routing) if a node receives a repeated request for the same data with a higher HTL. People have said that a hint of de-specialization is a good and useful thing, but nodes already have that in abundance (see http://hawk.freenetproject.org:8889/key_histogram_detail.txt). Oskar claims that he has observed what he calls a forked network (which I define to be a network which has split into two or more networks with no inter-connections, he has a different definition). It is possible that for a given key, multiple attractors for keys like it might exist, but since inserts are drawn towards one or the other, a request which follows the wrong attractor may not find its data. The solution is to merge these divergent attractors for the same key somehow. A brute-force solution would be for nodes to periodically send multiple requests for the same key to different nodes, then suggesting to the datasource nodes for the received data that they announce to each-other. Of course, we would need to take precautions to ensure that this mechanism could not be abused for malicious purposes. Ian. -- Ian Clarke[EMAIL PROTECTED] Founder Coordinator, The Freenet Projecthttp://freenetproject.org/ Chief Technology Officer, Uprizer Inc. http://www.uprizer.com/ Personal Homepage http://locut.us/ msg03553/pgp0.pgp Description: PGP signature
Re: [freenet-dev] Implemented random first hop
On Mon, Jul 29, 2002 at 12:19:37PM -0400, [EMAIL PROTECTED] wrote: I have seen a claim (on FMB) that one person can see more with build 489 than he could before. I've also seen claims that the noderefs that are available to a transient node behind a NAT firewall are different from the noderefs that are available to a non-transient node tunneling through a NAPT firewall. So, I *think* freenet is sort-of split by default. Hard to prove, though. Freenet DOES NOT WORK behind a NAT firewall if you do not tunnel (by port forwarding.) It does not work, period, transient or not. I still think that some warning/discussion on the freenet-dev list was warranted, since I don't normally keep track of the #freenet irc channel. For instance, what network is #freenet on? Why isn't that on the freenetproject web site in an obvious place, such as the Developer area About This Site section, or the FAQ? Because if we published it, we would have to move the discussions somewhere else... -- Oskar Sandberg [EMAIL PROTECTED] ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Implemented random first hop
On Mon, 29 Jul 2002, Oskar Sandberg wrote: On Mon, Jul 29, 2002 at 12:19:37PM -0400, [EMAIL PROTECTED] wrote: I have seen a claim (on FMB) that one person can see more with build 489 than he could before. I've also seen claims that the noderefs that are available to a transient node behind a NAT firewall are different from the noderefs that are available to a non-transient node tunneling through a NAPT firewall. So, I *think* freenet is sort-of split by default. Hard to prove, though. I think that those two nodes in question got different noderefs just because they initially connected to different parts of Freenet and learned different parts of it. They probably would start getting same noderefs after sufficient time and use (at least as long as the number of non-transient nodes on Freenet is smaller than rtMaxRefs). Freenet DOES NOT WORK behind a NAT firewall if you do not tunnel (by port forwarding.) It does not work, period, transient or not. Masquerading NATs do allow transient nodes to work normally, though. I still think that some warning/discussion on the freenet-dev list was warranted, since I don't normally keep track of the #freenet irc channel. For instance, what network is #freenet on? Why isn't that on To [EMAIL PROTECTED]: Try irc.openprojects.net the freenetproject web site in an obvious place, such as the Developer area About This Site section, or the FAQ? Because if we published it, we would have to move the discussions somewhere else... Why? Shouldn't interested individuals be allowed to learn more about the current/future inner workings of Freenet? If you're worried about the signal/noise ratio on #freenet, I doubt that's nothing a few bots and ops cannot solve. And if you want a really high ratio there's nothing stopping you from creating another channel for developers. -- Mika Hirvonen [EMAIL PROTECTED] http://nightwatch.mine.nu/ ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Freenet distribution/seedNodes
Matthew Toseland schrieb: I want the installer to see it's in a directory with lib/freenet.jar, lib/freenet-ext.jar, and seednodes.ref, and then install using those rather than downloading. Anyway, this is essential to improving routing and anonymity by reducing the number of nodes announcing to the centrally collected seedrefs... so if you could contact me, it would be helpful. OK, I just extended the webinstaller to look for the file lib\freenet.jar (relative to the installer binary). If it detects it, it won't try to download/unpack any files but will use the local files. It will use: lib\freenet.jar lib\freenet-ext.jar seednodes.ref (same directory as the installer) The files will be left untouched and not be deleted. The source is in CVS the new webinstall binary has been uploaded. Sebastian ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Implemented random first hop
On Mon, Jul 29, 2002 at 11:50:54PM +0300, Mika Hirvonen wrote: On Mon, 29 Jul 2002, Oskar Sandberg wrote: Freenet DOES NOT WORK behind a NAT firewall if you do not tunnel (by port forwarding.) It does not work, period, transient or not. Masquerading NATs do allow transient nodes to work normally, though. NO! Don't tell me how it works - I wrote the code in question and the protcol specification. A Freenet node, transient or not, needs to be able to accept new TCP connections from the Internet to work. A host behind a Masquerading NAT cannot do this (unless it has a port foward), so it will not work. Since connections are cached for some time after they are created, it may appear that it works, since some of the time reponses to requests will be sent over the connection that the masqueraded host established to send the request - but this is not always the case. Any time the established connection is busy (sending data for another request for example) when the peer attempts to respond to the masqueraded node it will attempt to make a new connection and fail. Any time the connection has already been closed (busy nodes do not keep idle connections open long - usually no more than 5-10 seconds), the peer will attempt to make a new connection and fail. These are not unusual or esoteric situations, they will occur more often than not. To the user, they manifest themselves simply as a lot timeouts and retries - and in the end they might get lucky, or they might not. A quick look through a public nodes contact attempts shows tons of entries like this: 356 0 0 tcp/192.168.20.12 Showing it has failed to connect to that node 356 times. This is not a non-transient node that it is trying to route to - the node is not dumb enough to try a broken route 356 times - this is a transient node that didn't received the response it was due 356 times. The myth that transient nodes work behind firewalls is hurtful to users whose time is wasted through frustrating performance (as if it isn't bad enough as it is) and hurtful to the network since the public nodes resources are wasted on failed connection attempts and pointless requests. Please stop perpetuating it. -- Oskar Sandberg [EMAIL PROTECTED] ___ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Improved Distribution Servlet
The Distribution Servlet now includes the Windows installer. You need to set the following config options: services=fproxy,nodestatus,nodeinfo,distribution distribution.class=freenet.node.http.DistributionServlet distribution.port=8891 distribution.allowedHosts=* # assuming you want to distribute to the whole internet, see below distribution.params.unpacked=/usr/make/cvs/freenet # or wherever you put the freenet tarball or CVS) distribution.params.winInstallerFilename=/usr/make/cvs/freenet/freenet-webinstall.exe # the filename of the windows webinstaller) You should now go to http://localhost:8891/ and create a distribution page. They last for 24 hours. Here's one I created earlier: http://amphibian.dyndns.org:8891/s4THodFe7Ns This contains a freenet.zip file, which contains the JAR files, seedrefs generated from your node, including your node's ref, the unix and windows install/run/config scripts, everything needed to start a node quickly, without involving freenetproject.org at all, thus enhancing anonymity, and producing probably significantly improved initial routing, due to not using the freenetproject.org seeds, which everyone uses and are therefore probably overloaded (and if they're not yet, they will be). msg03558/pgp0.pgp Description: PGP signature
[freenet-dev] Freenet presentation at DEFCON
For any of you planning to attend DEFCON this weekend in Vegas, you can see my pathetic attempt to fit a good overview of Freenet into a 50 minute time-slot at 5pm on Friday in the Privacy/Anonymity track. Ian. -- Ian Clarke[EMAIL PROTECTED] Founder Coordinator, The Freenet Projecthttp://freenetproject.org/ Chief Technology Officer, Uprizer Inc. http://www.uprizer.com/ Personal Homepage http://locut.us/ msg03562/pgp0.pgp Description: PGP signature
