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
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 tables. This way each node kn
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 - n
Winny Links : winny links>english 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.
___
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 Ja
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: /cvsroot/freenet/fr
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.
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 pSearchFai
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
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 f
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* sh
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
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 goo
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 problem
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, be
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 current
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 se
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 se
[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 other
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 h
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
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 y
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
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
> >
> > >
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 th
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 identi
> 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 wher
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 safeguards
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
follow
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
> >
> >
> -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 PR
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 id
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 r
> -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
> -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 stora
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:
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 fo
"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,
> - 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,
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 t
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
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 tha
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 PRO
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
_
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 Dok
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: "Dis
> -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 s
47 matches
Mail list logo
