Ian Clarke wrote:
snip
However, with what we have learned over the past few months, we need to
consider that NGR isn't ready for primetime and just throwing it in at
the deep-end to see if it would swim hasn't really worked.
There is also a cold financial reality here - we are barely keeping
Martin Stone Davis wrote:
1. We probably should go with Toad's idea of dropping the HTL system in
favor of a timeout-based system. This is a radical change, and needs to
be thought-out a bit more before it is implemented. However, I would
think we should be able to finish the design on paper
I would not oppose having a stable and usable network.
The question is how much time and effort is to revive
the non-ngr branch and update it with nio and how stable
will it be. I hope it will be OK.
I remember 0.3 with the infamous out-of-band key indexes,
then when the network fallen due to
Ian Clarke wrote:
Martin Stone Davis wrote:
1. We probably should go with Toad's idea of dropping the HTL system
in favor of a timeout-based system. This is a radical change, and
needs to be thought-out a bit more before it is implemented. However,
I would think we should be able to finish
You're serving almost as many successful requests as my entirely
socialised and co-operative node, and mine has completely failed to
deliver to about half the nodes in the table, despite receiving
thousands of requests from them. In other words, the normal node seems
to be a dark grey hole
BTW. Wasn't the whole point of NGRouting to ease the development by
allowing one to improve the algorithm simply by comparing the estimated
and observed routing times - the closer they are, the better ? Wouldn't it
make sense to perform such an observation, possibly by adding a new column
to
On Sat, Nov 29, 2003 at 01:58:56AM +0200, Jusa Saari wrote:
On Fri, 28 Nov 2003 19:26:52 +, Toad wrote:
Another possibility:
I would support allowing for DNFs, if the node that is doing the routing
can retry them. We would need some sort of load limiting mechanism other
than HTL.
If that is true, maybe BH nodes do harm to the network only because
they wipe their datastore often and so make content disappear... That
would not be that bad, however.
Indeed my node (always up to date to the very latest release) has been
captured by the BH node and it has been almost unable
We are forking the network, so that we have a 'stable' network with
classic routing, and the unstable network with NGR. This is for various
reasons Ian recently outlined on devl.
There may be some temporary service outages in the next few hours.
When service is believed to have been fully
On Fri, 28 Nov 2003 08:14:23 -0500, Andrew Rodland wrote:
BTW. Wasn't the whole point of NGRouting to ease the development by
allowing one to improve the algorithm simply by comparing the estimated
and observed routing times - the closer they are, the better ? Wouldn't it
make sense to
My node has recently pushed the Probability of success of an
incoming request maximum from 2 (been there from since NGRouting came to
unstable) to 4.5. Also, the datastore, incoming requests and succesfull
incoming requests are showing signs of specializations; very faint, but
what's interesting
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv17436/src/freenet/node
Modified Files:
Tag: stable
Node.java
Log Message:
5044:
Fork the stable network with a protocol number change.
Set default routing algo to classic.
Index: Node.java
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv17436/src/freenet
Modified Files:
Tag: stable
Version.java
Log Message:
5044:
Fork the stable network with a protocol number change.
Set default routing algo to classic.
Index: Version.java
Completed. Snapshots updated. Stable 5044 is now incompatible with the
unstable network. We have updated the seednodes generator script, we
have 3 nodes running 5044 generating seednodes...
On Sat, Nov 29, 2003 at 07:29:35PM +, Toad wrote:
We are forking the network, so that we have a
Update of /cvsroot/freenet/freenet/src/freenet/client/http
In directory sc8-pr-cvs1:/tmp/cvs-serv31289/src/freenet/client/http
Modified Files:
Tag: stable
NodeStatusServlet.java
Log Message:
5046:
Fix various bugs.
Port the fast RT filling code from NGR.
Index:
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv31289/src/freenet
Modified Files:
Tag: stable
Version.java OpenConnectionManager.java
Log Message:
5046:
Fix various bugs.
Port the fast RT filling code from NGR.
Index: Version.java
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv31289/src/freenet/node/rt
Modified Files:
Tag: stable
CPAlgoRoutingTable.java StoredRoutingTable.java
Log Message:
5046:
Fix various bugs.
Port the fast RT filling code from NGR.
Index:
Freenet stable build 5046 is now available. Use the update.sh or
freenet-webinstall.exe utilities to upgrade, or get
http://freenetproject.org/snapshots/freenet-latest.jar .
Fixes some bugs related to the recent network fork and reenabling of
classic routing in the stable branch.
--
Matthew J
On Sat, 2003-11-29 at 12:48, Martin Stone Davis wrote:
Ian Clarke wrote:
What exactly is unobtanium routing?
Ubobtanium routing was first proposed by me as Improving NGR in:
http://article.gmane.org/gmane.network.freenet.devel/7791
That's the article about whether you should have your
On Sat, Nov 29, 2003 at 04:48:28PM -0500, Edward J. Huff wrote:
On Sat, 2003-11-29 at 12:48, Martin Stone Davis wrote:
Ian Clarke wrote:
What exactly is unobtanium routing?
Ubobtanium routing was first proposed by me as Improving NGR in:
OK, here is an idea I have been working on for a while. It's a bit long, so please
respond to it piecemeal.
Here is a solution that I think can make NGrouting work correctly, aid load balancing,
lower Query rejecting, prevent users from overloading the network, and end world
hunger. Well,
Options:
1. Maybe rFT will recover after the new code has been running for a
while and served some more successful requests. Action: commit the code
and wait. Doesn't appear promising but then we'll see.
2. Set rFT to infinity. Failure is not an option because DNF goes right
back to the original
__
The idea here is not to turn the network into a broadcast search, but to
abolish DataNotFound, something that NGRouting clearly can't handle, and
which has NOT been successfully performing its stated goal of limiting
load usage, and replace it with a combination of
Could you or someone who thinks they understand this please give an
illustration of how this works? I'm way too confused.
-Martin
[EMAIL PROTECTED] wrote:
OK, here is an idea I have been working on for a while. It's a bit long, so please respond to it piecemeal.
Here is a solution that I
LOL, yeah. This is exactly what you and Toad were talking about, plus lots of other
goodies thrown in. I was so busy writing this that I wasn't reading my email, now as I
look back through, I see the two of you were descussing many of the issues that I
struggled to sort out to write this. It
"Martin Stone Davis" m0davis-yBeKhBN/[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
Ian Clarke wrote: snip However, with what we have learned over the past few months, we need to consider that NGR isn't ready for primetime and just throwing it in at the deep-end to see if it
On November 29, 2003 03:30 pm, Toad wrote:
Completed. Snapshots updated. Stable 5044 is now incompatible with the
unstable network. We have updated the seednodes generator script, we
have 3 nodes running 5044 generating seednodes...
On Sat, Nov 29, 2003 at 07:29:35PM +, Toad wrote:
We
[EMAIL PROTECTED] wrote:
LOL, yeah. This is exactly what you and Toad were talking about, plus
lots of other goodies thrown in. I was so busy writing this that I
wasn't reading my email, now as I look back through, I see the two of
you were descussing many of the issues that I struggled to sort
28 matches
Mail list logo
