-Original Message-
From: Toad [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 9:50 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [freenet-dev] Stable build 5047
* Some significant improvements to NGRouting. Since classic routing is
the default on the stable
If your ini file was created by an ngr-build it will still state ngr.
However, since the config value is actually commented out by the '%' sign
whatever the current nodes default value ('classic') is will be used.
/N
- Original Message -
From: Costas Dokolas [EMAIL PROTECTED]
To:
No, I think the code will use the choosen type of rt.
Check the implementation section on
'http://localhost:/servlet/nodestatus/nodestatus.html' for info on
what your node is using.
/N
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Costas
Someone on devl is running a node which reports itself as being build
. Is this a homebrew/experimental build of some sort? Just curious
what all it's doing; I noticed that my web interface was reporting
(Latest: ) so I dug around to see where it was coming from.
-s
The catch is: it's not commented out! (either with a # or with a %)
Basically, the question is isn't stable now using classic routing whatever
the config setting?
Is there a way to check the running setting from a servlet?
Doc
-Original Message-
From: Niklas Bergh [mailto:[EMAIL
S wrote:
Someone on devl is running a node which reports itself as being build
. Is this a homebrew/experimental build of some sort? Just curious
what all it's doing; I noticed that my web interface was reporting
(Latest: ) so I dug around to see where it was coming from.
We suspected that
On Thu, 04 Dec 2003 12:12:47 +
Ian Clarke [EMAIL PROTECTED] wrote:
We suspected that some irritating person might abuse the new build
available system in this way.
The IP of that node has posted constructive stuff to devl, so I see it
sort of like Zlatin's blackhole node: better the issue
Is there a chance the node behaves as routing-only node? (i.e. I don't
have the data myself but I can route like the wind!)
As a correlation:
- What could be the benefits of routing-only nodes? (i.e. low storage
space, assuming they are on very fast connections) Perhaps extra anonymity
for the
- What could be the benefits of routing-only nodes? (i.e.
low storage space, assuming they are on very fast
connections) Perhaps extra anonymity for the network?
A big problem here is that data still has to pass through the routing
nodes.. Routing nodes has to update their routing table,
"When a notoriouskey becomes known (and the key of e.g. TFE would
certainly benotorious), there will certainly be court orders against
allknown Freenet nodes barring them from routing that key. And
ifthey continue to route the key in such a way that they can beproved to
have routed the key,
On 2003-12-03T13:03:07-0800, Martin Stone Davis wrote:
That's fine too. And here's an even better idea: to make it easier to
read if DDRA is near 0 or 1, we should display the sequence like this:
0(124) 1 0(56) 1 to indicate a sequence of 124 0's followed by a 1
followed by 56 0's
Just curious, what advantage would this have over
something like http over iip (which doesn't exist as
far as I know)? Your description is kind of hard to
follow. How about scanning and posting some 'napkin'
diagrams to make your proposal clearer?
--- Edward J. Huff [EMAIL PROTECTED] wrote:
-Original Message-
From: Niklas Bergh [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2003 4:03 PM
To: 'Discussion of development issues'
Subject: RE: Re[2]: [freenet-dev] black hole report
- What could be the benefits of routing-only nodes? (i.e.
low storage space,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Costas Dokolas
Sent: den 4 december 2003 15:31
To: Discussion of development issues
Subject: RE: Re[2]: [freenet-dev] black hole report
-Original Message-
From: Niklas Bergh
On Thu, 04 Dec 2003 07:03:45 -0600
S [EMAIL PROTECTED] wrote:
How about distributing the latest build number through a DBR-based
freesite, published by one of the developers?
To clarify a bit here, I didn't mean that users should have to visit a
freesite to determine whether or not a new
Martin Stone Davis wrote:
Let DDRA = the decaying decaying running average
Let decayingDecayFactor=decayFactor * MIN(DRA,1-DRA)
Then compute the new decaying decaying running average as:
DDRA := DDRA*(1-decayingDecayFactor) + [1 or 0]*decayingDecayFactor
Attached is my attempt to implement this
-Original Message-
From: Niklas Bergh [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2003 4:49 PM
To: 'Discussion of development issues'
Subject: RE: Re[2]: [freenet-dev] black hole report
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
On Thu, Dec 04, 2003 at 04:30:49PM +0200, Costas Dokolas wrote:
-Original Message-
From: Niklas Bergh [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2003 4:03 PM
To: 'Discussion of development issues'
Subject: RE: Re[2]: [freenet-dev] black hole report
- What
Kendy Kutzner wrote:
On 2003-12-03T13:03:07-0800, Martin Stone Davis wrote:
That's fine too. And here's an even better idea: to make it easier to
read if DDRA is near 0 or 1, we should display the sequence like this:
0(124) 1 0(56) 1 to indicate a sequence of 124 0's followed by a 1
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv306/src/freenet
Modified Files:
ConnectionHandler.java
Log Message:
Major refactoring. Moved all variables handling trailer sending state into a separate
inner class and added some extra state
Note also that FreeMixNet deals in connections, not content.
To get content, you get a connection to a key which knows
where to get the content, and discuss how to arrange delivery.
A very interesting and imho compelling view - seperating the anonymization
of who is contacting whom from where
On Thu, 4 Dec 2003, Newsbyte wrote:
When a notorious
key becomes known (and the key of e.g. TFE would certainly be
notorious), there will certainly be court orders against all
known Freenet nodes barring them from routing that key. And if
they continue to route the key in such a way that
On Thu, Dec 04, 2003 at 05:18:14PM +0200, Costas Dokolas wrote:
-Original Message-
From: Niklas Bergh [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 04, 2003 4:49 PM
To: 'Discussion of development issues'
Subject: RE: Re[2]: [freenet-dev] black hole report
-Original
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv23667/src/freenet/node/states/FNP
Modified Files:
NewDataRequest.java.BlackHole
Log Message:
slightly smarter black hole, more work to follow
Index: NewDataRequest.java.BlackHole
If, as has been reported, a node which always DNFs gets an increasing
number of requests then there is a bug in NGR - plain and simple - and
it should be easy enough to track down.
*This* should be our focus, not iTTL which seems like [yet another]
hasty solution to a problem we haven't found
Ian Clarke wrote:
e = pDF*tDF + pDNF*(tDNF * tSearchFailed)
oops, that should be:
e = pDF*tDF + pDNF*(tDNF + tSearchFailed)
^
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
btw the black hole code is already being adapted to do smarter things that just
dnf. Right now one can set the ratio of requests to be DNFd versus those being
dropped; its trivial to make it accept and route certain % of requests as well.
This should help us test how other nodes see the black
[EMAIL PROTECTED] wrote:
btw the black hole code is already being adapted to do smarter things that just
dnf. Right now one can set the ratio of requests to be DNFd versus those being
dropped; its trivial to make it accept and route certain % of requests as well.
This should help us test how
On Thu, Dec 04, 2003 at 08:07:00PM +, Ian Clarke wrote:
If, as has been reported, a node which always DNFs gets an increasing
number of requests then there is a bug in NGR - plain and simple - and
it should be easy enough to track down.
*This* should be our focus, not iTTL which seems
On Thu, Dec 04, 2003 at 08:07:00PM +, Ian Clarke wrote:
If, as has been reported, a node which always DNFs gets an increasing
number of requests then there is a bug in NGR - plain and simple - and
it should be easy enough to track down.
*This* should be our focus, not iTTL which seems
One other thing: if we are not going to implement iTTL, at the VERY
least we should drop the failure table. 'We routed to a node that was
less likely to get the key, but faster' is ABSOLUTELY NOT a good enough
reason for blocking all requests for the key for the next half hour.
Fortunately
On Thu, 2003-12-04 at 09:43, Jim Dixon wrote:
On Thu, 4 Dec 2003, Newsbyte wrote:
[some political questions...]
[some good political answers... better than what I was going to say.]
In fact the hurdles are trivial. The police don't have to bust everyone.
All they need do is identify a
m0davis suggested that we should use pSearchFailed (or more detailed
stats), despite backoff. The reason we don't do this is that if we did,
a node in the RT would get a few queries and then its pSearchFailed
would increase, and subsequently it would not be routed to at all for a
very long time,
Ian Clarke wrote:
If, as has been reported, a node which always DNFs gets an increasing
number of requests then there is a bug in NGR - plain and simple - and
it should be easy enough to track down.
*This* should be our focus, not iTTL which seems like [yet another]
hasty solution to a
Martin Stone Davis wrote:
Michael Wiktowy wrote:
Correct me if I am wrong here but ...
All of those people who have been posting (or expecting) these
wonderfully symmetric single peaked bell-shaped request distribution
curves may be misrating the health of their node by thinking that this
is a
Toad wrote:
m0davis suggested that we should use pSearchFailed (or more detailed
stats), despite backoff. The reason we don't do this is that if we did,
a node in the RT would get a few queries and then its pSearchFailed
would increase, and subsequently it would not be routed to at all for a
very
On Thu, Dec 04, 2003 at 05:52:50PM -0800, Martin Stone Davis wrote:
Ian Clarke wrote:
If, as has been reported, a node which always DNFs gets an increasing
number of requests then there is a bug in NGR - plain and simple - and
it should be easy enough to track down.
*This* should be our
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv12328/src/freenet
Modified Files:
Version.java
Log Message:
6375:
Logging, mostly. Clarify some routing code.
Index: Version.java
===
RCS
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv12328/src/freenet/node/rt
Modified Files:
NGRoutingTable.java StandardNodeEstimator.java
Log Message:
6375:
Logging, mostly. Clarify some routing code.
Index: NGRoutingTable.java
On Thu, Dec 04, 2003 at 06:20:35PM -0800, Martin Stone Davis wrote:
Toad wrote:
m0davis suggested that we should use pSearchFailed (or more detailed
stats), despite backoff. The reason we don't do this is that if we did,
a node in the RT would get a few queries and then its pSearchFailed
Misleading Article : seen on www.hardocp.com , a major hardware/internet news site
---
This message has been sent by the iip-smtp gateway.
Please send a mail to [EMAIL PROTECTED] if this service has been abused.
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv14403/src/freenet
Modified Files:
Version.java
Log Message:
6376: Make 6374 mandatory
Index: Version.java
===
RCS file:
Misleading Article : seen on www.hardocp.com ,a major hardware/internet news site
Untraceable Users Traced; How embarrassing is this? A supposed untraceable anonymous
network gets busted by the copsÂ…guess they will have to change that whole
untraceable marketing strategy they had going. A
Winny Links : winny linksenglish guide-
www.geocities.co.jp/AnimeComic-Palette/1946/winnyguide/winny.html
---
This message has been sent by the iip-smtp gateway.
Please send a mail to [EMAIL PROTECTED] if this service has been abused.
Unstable 6376 is in CVS. Highlights since 6371:
Implementation of selective accept under load. This should improve
specialization and success ratios under load.
Bugfixes.
Make 6374 mandatory - we will no longer accept requests from 6374, nor
will we route to 6374 nodes. This is the unstable net -
DigitalE wrote:
Request for comments:
New variable:
Peak Specialization (PS)
Nodes look for a peak in their datastore around a
certain key and store
its position as their Peak Specialization (PS) which
is advertised to
other nodes whenever a connection is made and stored
in routing
46 matches
Mail list logo
