This problem is due to having fewer estimators than
keys in the keyspace (due to resource constraints :)
and interpolating between estimators. The attack is
exploiting this interpolation. I propose using
dynamic estimators to thwart this attack. If an
estimator is "moving" a lot it is either due
On Tuesday 28 October 2003 05:15 pm, Tracy R Reed wrote:
> On Tue, Oct 28, 2003 at 05:44:43PM -0500, Nick Tarleton spake thusly:
> > > Right now with
> > > the totally random routing due to no specialization freenet can only
> > > store as much retrievable data as 25*n where n is the average size o
Quoting Toad <[EMAIL PROTECTED]>:
> Is the crash reproducible?
Yes, it happened once more. I'll grab the logs again next time it happens.
j.
>
> On Mon, Oct 27, 2003 at 04:41:50PM -0600, J wrote:
>
> > Function=(null)+0x403DFC88
> > Library=/opt/sun-jdk-1.4.2.01/jre/lib/i386/client/libjvm.s
On Monday 27 October 2003 09:32 pm, Tom Kaitchuck wrote:
> I don't see anything about bandwidth. Here I what I currently have:
>
> Current routingTime
> 14ms
>
> Curent messageSendTimeRequest
> 113ms
>
> Active pooled jobs
> 105 (87.5%)
>
> Available threads
> 75
>
> It's normal for the node to som
On Tuesday 28 October 2003 05:24 pm, Toad wrote:
> What makes you think this wouldn't be grossly exploitable? Publicly
> writable TUKs seem a bad idea to me... the question is whether they are
> worse than the alternative.
Well, not strictly publicly writable. (They have to be signed with the priv
On Tue, Oct 28, 2003 at 05:44:43PM -0500, Nick Tarleton spake thusly:
> > Right now with
> > the totally random routing due to no specialization freenet can only store
> > as much retrievable data as 25*n where n is the average size of the
> > datastores on freenet and 25 is the current max htl. No
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
$ java freenet.Version
Freenet: Fred 0.6 (protocol 1.47) build 6286 (last good build: 6280)
$ java -version
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mix
On Tue, Oct 28, 2003 at 11:22:02PM +, Toad wrote:
> I have a better attack. You are targetting a particular area of the
> keyspace. Request a long stream of random keys very close to the target
> key. They will all DNF, and reduce the pDNF in that area of each node
> the node routes the request
HALLELUJAH!
--
"I love deadlines. I love the whooshing sound they make as they go by."
- Douglas Adams
Nick Tarleton - [EMAIL PROTECTED] - PGP key available
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/l
Is the crash reproducible?
On Mon, Oct 27, 2003 at 04:41:50PM -0600, J wrote:
> Function=(null)+0x403DFC88
> Library=/opt/sun-jdk-1.4.2.01/jre/lib/i386/client/libjvm.so
>
> NOTE: We are unable to locate the function name symbol for the error
> just occurred. Please refer to release docume
Howdy all!
Granted, I've had my 5028 node up for nearly 2.5 days straight now and had
lots of good connections, I took it down to upgrade to 5029! Since that
time I have gotten several MB more in data transfer than I've had in over
24 hours! (in just under 20 minutes!)
It's back up to the tran
On Tue, Oct 28, 2003 at 12:53:24PM +0100, Some Guy wrote:
> --- Toad <[EMAIL PROTECTED]> wrote:
> > On Mon, Oct 27, 2003 at 01:54:16PM +0100, Some Guy wrote:
> > > --- Nick Tarleton <[EMAIL PROTECTED]> wrote:
> > > > I have heard a lot about Freenet's emergent behavior and would like to
> > >
On Tue, Oct 28, 2003 at 10:35:28AM -0800, Tracy R Reed wrote:
> On Tue, Oct 28, 2003 at 11:54:11AM +, Ian Clarke spake thusly:
> > No, optimally every node caches everything and there is no
> > specialization whatsoever.
>
> But this greatly reduces the total data storage capacity of the netw
On Tue, Oct 28, 2003 at 12:03:06PM -0600, Tom Kaitchuck wrote:
> On Tuesday 28 October 2003 05:34 am, Some Guy wrote:
> > If anyone(Frost user) can write to the TUK how is it better/different than
> > a KSK? Has your TUK idea changed? I thought the idea was to allow more
> > complicated signing po
I have a better attack. You are targetting a particular area of the
keyspace. Request a long stream of random keys very close to the target
key. They will all DNF, and reduce the pDNF in that area of each node
the node routes the request to, until the estimator is so low that it
tries a different n
On Monday 27 October 2003 07:34 pm, Toad wrote:
> Data size is indeed taken into account in routing. However, a node with
> intermittent connectivity is not going to work very well, and one on a
> 33.6/57.6 connection will be even worse. NGRouting should detect this
> and work around it by ignoring
> Right now with
> the totally random routing due to no specialization freenet can only store
> as much retrievable data as 25*n where n is the average size of the
> datastores on freenet and 25 is the current max htl. No bueno.
I would think it'd be greater because although the amount of retrievab
> The newbies (and not only they) judge the Freenet performance by the
> number of broken images on their Web Interface. And that is bad. ("Only
> 2 of 5 images... Freenet sucks!" or "Yippee! 4 images! Freenet has improved.")
my web interfaces grown from 2 to 3 in these days of new builds...
(TFE
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv1648/src/freenet
Modified Files:
Version.java
Log Message:
d'oh, accept 0.5...
Index: Version.java
===
RCS file: /cvsroot/freenet/freenet/
After months of work we have finally decided that the "Next Generation
Routing" code is ready for wider testing and have thus merged it into
the "stable" build of Freenet.
Next Generation Routing or NGR represents a MAJOR change to the way
freenet searches for data, while still preserving the u
On Tuesday 28 October 2003 01:52 pm, [EMAIL PROTECTED] wrote:
> >So if we were to have a Project page that had all the latest versions of
> >Freenet and links to all of the various indexes, ( and if people were
> > really anal you could separate all those that don't censer their content
> > onto a
On Tue, Oct 28, 2003 at 01:03:58AM -0800, Mike Stump wrote:
> > > Connection attempts 1193
> > > Connection successes 1047
> > > Consecutive failed connections 0
> > > Probability of connection failure 0.017196883744822623
> >
> > Umm, why is this bad?
>
> On my node, connectingTime is in the 10
Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcing
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/states/announcing
Modified Files:
Tag: stable
AnnouncementRequestToken.java Announcing.java
ExecuteAnnouncement.java NewInitialRequest.java
Update of /cvsroot/freenet/freenet/src/freenet/node/http/templates
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/http/templates
Modified Files:
Tag: stable
fproxyInsert.tpl
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Nex
Update of /cvsroot/freenet/freenet/src/freenet/interfaces/servlet
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/interfaces/servlet
Modified Files:
Tag: stable
HttpServletContainer.java ServletContainer.java
Log Message:
5029: Merge from unstable after months of work. MASSI
Update of /cvsroot/freenet/freenet/src/freenet/node/states/maintenance
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/states/maintenance
Modified Files:
Tag: stable
Checkpoint.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights
Update of /cvsroot/freenet/freenet/src/freenet/transport
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/transport
Modified Files:
Tag: stable
AbstractSelectorLoop.java ListenSelectorLoop.java
NIOReader.java ReadSelectorLoop.java
ThrottledSelectorLoop.java W
On Tue, Oct 28, 2003 at 03:44:21AM -0800, [EMAIL PROTECTED] wrote:
> How about releasing a stable build 5029 that does not talk to those rogue
> anti-NGR nodes (6163 <= build number <= 6279)?! (I'm tired of blocking
> those in my routing table with my firewall.)
>
> Unfortunately the routing algor
On Tue, Oct 28, 2003 at 08:49:07PM +0100, [EMAIL PROTECTED] wrote:
> >2. Send mails to announce and devl every time a new build is released, naming its
> >changes. Then, people can upgrade only once they see this message and they decide
> >they like the changes. This is more work for
> the devs
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FCP
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/states/FCP
Modified Files:
Tag: stable
ClientGetToken.java ClientPutToken.java FCPFeedbackToken.java
NewClientGet.java NewClientPut.java NewClientReque
Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcement
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/states/announcement
Modified Files:
Tag: stable
AnnouncementDone.java AnnouncementState.java
CompletePending.java ExecutePending.java LastNode
On Tue, Oct 28, 2003 at 08:54:35PM +0100, [EMAIL PROTECTED] wrote:
> >6285: seal the breach. 1.47/1.46 is now interchangeable. Preparatory for stable
> >merge, which is imminent.
>
> yippie! ;)
>
> >Index: Version.java
> >===
> >RCS
Update of /cvsroot/freenet/freenet/src/freenet/support
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support
Modified Files:
Tag: stable
BlockingQueue.java CryptBucket.java Fields.java
FileBucket.java FileLoggerHook.java LRUQueue.java
LimitCounter.java Log
Update of /cvsroot/freenet/freenet/src/freenet/support/test
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support/test
Modified Files:
Tag: stable
FieldsTest.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next Generation Ro
Update of /cvsroot/freenet/freenet/src/freenet/session
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/session
Modified Files:
Tag: stable
FnpLink.java FnpLinkManager.java Link.java PlainLink.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Update of /cvsroot/freenet/freenet/src/freenet/support/io
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support/io
Modified Files:
Tag: stable
Bandwidth.java NIOInputStream.java NIOOutputStream.java
ThrottledInputStream.java
Log Message:
5029: Merge from unstable
Update of /cvsroot/freenet/freenet/src/freenet/support/servlet/http
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support/servlet/http
Modified Files:
Tag: stable
HttpServletRequestImpl.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
High
Update of /cvsroot/freenet/freenet/src/freenet/support/mime
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support/mime
Modified Files:
Tag: stable
MIME_multipart.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next Generatio
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/states/FNP
Modified Files:
Tag: stable
FNPFeedbackToken.java NewDataRequest.java
NewInsertRequest.java NewRequest.java NewVoid.java
Added Files:
Update of /cvsroot/freenet/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv25857
Modified Files:
Tag: stable
.cvsignore Makefile README TODO build.xml
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next Generation Routing, massive related c
Update of /cvsroot/freenet/freenet/src/freenet/node/http
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/http
Modified Files:
Tag: stable
BookmarkManagerServlet.java DistributionServlet.java
NodeInfoServlet.java
Added Files:
Tag: stable
ColoredPix
Update of /cvsroot/freenet/freenet/src/freenet/node/ds
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/ds
Modified Files:
Tag: stable
FSDataStoreElement.java KeyCollisionException.java
KeyInputStream.java
Added Files:
Tag: stable
StoreIOException.
Update of /cvsroot/freenet/freenet/src/freenet/node/http/infolets
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/http/infolets
Modified Files:
Tag: stable
DefaultInfolet.java EnvironmentInfolet.java
GeneralInfolet.java
Log Message:
5029: Merge from unstable af
Update of /cvsroot/freenet/freenet/src/freenet/message/client
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/message/client
Modified Files:
Tag: stable
ClientGet.java ClientHello.java ClientInfo.java
ClientMessage.java ClientPut.java DataChunk.java
Generate
Update of /cvsroot/freenet/freenet/src/freenet/message
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/message
Modified Files:
Tag: stable
Accepted.java AnnouncementComplete.java
AnnouncementExecute.java AnnouncementFailed.java
AnnouncementReply.java DataIns
Update of /cvsroot/freenet/freenet/src/freenet/interfaces
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/interfaces
Modified Files:
Tag: stable
BaseLocalNIOInterface.java FreenetConnectionRunner.java
Interface.java LocalHTTPInterface.java LocalInterface.java
Update of /cvsroot/freenet/freenet/src/freenet/crypt/ciphers
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/crypt/ciphers
Modified Files:
Tag: stable
Rijndael_Algorithm.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next Gen
Update of /cvsroot/freenet/freenet/src/freenet/diagnostics
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/diagnostics
Modified Files:
Tag: stable
FileEventList.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next Generation R
Update of /cvsroot/freenet/freenet/src/freenet/crypt
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/crypt
Modified Files:
Tag: stable
CipherOutputStream.java DSA.java DSAGroup.java
DSAPublicKey.java DSASignature.java DiffieHellman.java
Yarrow.java
Added Fi
Update of /cvsroot/freenet/freenet/src/freenet/client/metadata
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/client/metadata
Modified Files:
Tag: stable
DateRedirect.java VersionCommand.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
High
Update of /cvsroot/freenet/freenet/src/freenet/support/servlet
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support/servlet
Modified Files:
Tag: stable
ServletInputStreamImpl.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
*
Update of /cvsroot/freenet/freenet/src/freenet/support/graph
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/support/graph
Modified Files:
Tag: stable
Bitmap.java DibEncoder.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next
Update of /cvsroot/freenet/freenet/src/freenet/node/states/data
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/node/states/data
Modified Files:
Tag: stable
DataState.java ReceiveData.java SendData.java
Added Files:
Tag: stable
TrailerWriteCallbackMessage.java
Update of /cvsroot/freenet/freenet/src/freenet/presentation
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/presentation
Modified Files:
Tag: stable
FCPRawMessage.java FNPRawMessage.java FreenetProtocol.java
Log Message:
5029: Merge from unstable after months of work. MASSIV
Update of /cvsroot/freenet/freenet/src/freenet/message/client/FEC
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/message/client/FEC
Modified Files:
Tag: stable
FECDecodeSegment.java FECEncodeSegment.java
FECMakeMetadata.java FECSegmentFile.java
FECSegmentSp
Update of /cvsroot/freenet/freenet/src/freenet/fs/dir
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/fs/dir
Modified Files:
Tag: stable
Buffer.java CircularBuffer.java FSDirectory.java
FileNumber.java NativeFSDirectory.java NullBuffer.java
Log Message:
5029: Merge
Update of /cvsroot/freenet/freenet/src/freenet/config
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/config
Modified Files:
Tag: stable
Config.java Option.java RandomPortOption.java Setup.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Hig
Update of /cvsroot/freenet/freenet/src/freenet/client/cli
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/client/cli
Modified Files:
Tag: stable
CLIFNPClient.java PutCommand.java
Log Message:
5029: Merge from unstable after months of work. MASSIVE changes.
Highlights:
* Next
Update of /cvsroot/freenet/freenet/src/freenet/client/http
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/client/http
Modified Files:
Tag: stable
ContextManager.java FproxyServlet.java HttpServletRunner.java
InsertServlet_.java NodeStatusServlet.java SFRContext.java
Update of /cvsroot/freenet/freenet/src/freenet/client
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/client
Modified Files:
Tag: stable
AutoBackoffNodeRequester.java AutoRequester.java
ClientCore.java ClientEventListener.java
ClientMessageHandler.java Clien
Update of /cvsroot/freenet/freenet/src/freenet/thread
In directory sc8-pr-cvs1:/tmp/cvs-serv25857/src/freenet/thread
Modified Files:
Tag: stable
FastThreadFactory.java QThreadFactory.java ThreadFactory.java
Added Files:
Tag: stable
ThreadStatusSnapshot.java YThreadFact
>6285: seal the breach. 1.47/1.46 is now interchangeable. Preparatory for stable
>merge, which is imminent.
yippie! ;)
>Index: Version.java
>===
>RCS file: /cvsroot/freenet/freenet/src/freenet/Version.java,v
>retrieving revision 1.4
>So if we were to have a Project page that had all the latest versions of
>Freenet and links to all of the various indexes, ( and if people were really
>anal you could separate all those that don't censer their content onto a
>subpage.)
as you will notice there is already a freesite which prov
>I submit these as possible ways to prevent another fiasco like that following the
>fork. I do not demand that either be implemented.
>
>1. Before a major change such as this is taken, which will modify people's nodes
>severely and may cause some not to want to upgrade, send mails to announce and
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv10051/src/freenet
Modified Files:
Version.java
Log Message:
Index: Version.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet/Version
@ Tom Kaitchuck [EMAIL PROTECTED]
@ Aureliano Rama [EMAIL PROTECTED]
please reread my original post. I mentioned "legal issues" as an "old
reason". All this has been discussed ad infinitum in the older threads.
I wanted to add only ONE new point to the list of pros and cons: In the
old days, when
On Tue, Oct 28, 2003 at 11:54:11AM +, Ian Clarke spake thusly:
> No, optimally every node caches everything and there is no
> specialization whatsoever.
But this greatly reduces the total data storage capacity of the network to
just the average size of one datastore.
--
Tracy Reed
http://c
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv6483/src/freenet
Modified Files:
Version.java
Log Message:
6285: seal the breach. 1.47/1.46 is now interchangeable. Preparatory for stable merge,
which is imminent.
Index: Version.java
On Tuesday 28 October 2003 06:44 am, [EMAIL PROTECTED] wrote:
> > Don't we want Freenet to be as self contained as possible, without
> > all the issues of depending on the regular web for anything besides
> > initial download?
>
> Ah, so we already *have* to access the regular web to start at all?
[EMAIL PROTECTED] wrote:
I mean, we are caching them if they come in from the network with no client involvement, but caching ones that have only been through the client in the local encrypted store. That way, they wouldn't look any different than the rest of the keyspace. See my other mail.
Ah,
I submit these as possible ways to prevent another fiasco like that following the
fork. I do not demand that either be implemented.
1. Before a major change such as this is taken, which will modify people's nodes
severely and may cause some not to want to upgrade, send mails to announce and devl
On Tuesday 28 October 2003 05:34 am, Some Guy wrote:
> If anyone(Frost user) can write to the TUK how is it better/different than
> a KSK? Has your TUK idea changed? I thought the idea was to allow more
> complicated signing policies for groups of people.
no, that is something else. (not a bad id
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv28319/src/freenet/node
Modified Files:
SmartFailureTable.java FailureTable.java
Log Message:
have fun toad :)
Index: SmartFailureTable.java
==
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv25916/src/freenet/node
Modified Files:
SmartFailureTable.java FailureTable.java
Log Message:
initial commit
Index: SmartFailureTable.java
I mean, we are caching them if they come in from the network with no client
involvement, but caching ones that have only been through the client in the local
encrypted store. That way, they wouldn't look any different than the rest of the
keyspace. See my other mail.
-Original Message-
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv23686/src/freenet/node
Added Files:
SmartFailureTable.java
Log Message:
initial commit
--- NEW FILE: SmartFailureTable.java ---
package freenet.node;
import freenet.Core;
import freenet.Key;
import
On Tuesday 28 October 2003 01:38 am, Martin Stone Davis wrote:
> > This has been dealt with as far as I am concerned. All we have to do is
> > cache normally - in the short term, cache if and only if pcaching says
> > so, taking into account client access, and have a higher level cache of
> > only
Tom Kaitchuck <[EMAIL PROTECTED]> writes:
> On Monday 27 October 2003 10:20 pm, Edgar Friendly wrote:
> > Toad <[EMAIL PROTECTED]> writes:
> > > > Caching data is just an optimization designed to cut down the work on
> > > > the network by having repeated requests travel shorter distances.
> > >
>
That juts means it retried on a different route... and the new route
happened to have the data right there.
--Brandon
On Tue, 10/28/03 at 10:57:07 -0800, Doug Bostrom wrote:
> This seemed rather odd to me, but perhaps it's normal?
>
> Retrieving this key:
>
> [EMAIL PROTECTED]/magick/1//?htl=15
This seemed rather odd to me, but perhaps it's normal?
Retrieving this key:
[EMAIL PROTECTED]/magick/1//?htl=15
yielded a DNF via Fproxy, which suggested a retry at 15 hops. I pressed
"Retry" and the site popped up instantly in my browser.
Sorry if this is just noise.
--
"The reason we start
[EMAIL PROTECTED] wrote:
My thesis is: If we are caching the naughty keys in the main store normally, then why will the AAIR think we are trying to hide them?
?? Well, if we are caching everything, then we aren't hiding, and yes
the AAIR would not think we are hiding anything. But then we would
My thesis is: If we are caching the naughty keys in the main store normally, then why
will the AAIR think we are trying to hide them?
-Original Message-
> This has been dealt with as far as I am concerned. All we have to do is
> cache normally - in the short term, cache if and only if pca
But couldn't 50 (or some other) % come from chance?
What would give a negative on BOTH attacks?
And when the keys are unpopular... ehh.
I had an idea a while back that could help that, where nodes that need to fill their
datastores can request other nodes to send them random keys.
-Original M
> Currently I have the impression that with only 3 clicks from the Web
> Interface you get to questionable material. That is a very nice thing
> for the 9 o'clock news. "Install Freenet and child porn is only 3 clicks
> away!"
Well, actually illegal porno and sofwares and mp3s are only 2 clicks
a
I assume that we should also remove items from the table whenever we
succeed with a request for that key..
Other than that I think that this might be a good thing to have.
/N
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Toad
> Sent: den 28 okto
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv21636/src/freenet/node/rt
Modified Files:
ResponseTimeEstimator.java
Log Message:
removed a bunch of unneccesary double synchronizations and added indenting.
Index: ResponseTimeEstimator.java
===
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv13296/src/freenet
Modified Files:
OpenConnectionManager.java
Log Message:
My 'Lesser optimization' also added an accouting bug. Thanks to Dave Hooper for
spotting it.
Index: OpenConnectionManager.java
=
Some Guy wrote:
No, optimally every node caches everything and there is no
specialization whatsoever.
Well, I guess that's "optimal" for redundancy. It certainly isn't
"optimal" from a storage or bandwidth point of view. Maybe that's
the bush we're beating around.
It is optimal for minimizing re
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Hooper
> Sent: den 27 oktober 2003 20:55
> To: [EMAIL PROTECTED]
> Subject: [freenet-dev] Re: [freenet-CVS]
> freenet/src/freenetOpenConnectionManager.java, 1.147, 1.148
>
>
> Could someone plea
On October 27, 2003 08:45 pm, Toad wrote:
> Ok, so the proposal:
>
> Keep the current failure table. It should probably be made very large.
>
> Create a large secondary failure table. Keys in this table will still be
> routed, but are not counted for statistical purposes, nor do they affect
> estim
On October 27, 2003 08:26 pm, Toad wrote:
> > The other thing this sort of usage pattern does is make other nodes
> > see higher values for SendFailed than are real. The
> > DecayingRunningAverage class is very quick to move to 1.0... I do have a
> > variant on this class that uses a window of se
On Sat, 25 Oct 2003 14:37:48 -0700 Nick Tarleton <[EMAIL PROTECTED]>
wrote:
> On Wednesday 22 October 2003 10:27 am, [EMAIL PROTECTED] wrote:
>> The user himself can add bookmarks using the Bookmark Manager.
>> And if there aren't any bookmarks defined, instead of showing an
>> empty "Bookmarks" bo
--- Ian Clarke <[EMAIL PROTECTED]> wrote:
> > You are suggesting that specailization makes no sense in small
> > networks and that freenet does what is optimal. Ian, please think
> > about this. In a tiny network were every node was connected to every
> > other one, specialization still makes
--- Toad <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 27, 2003 at 01:18:14PM +0100, Some Guy wrote:
> > --- Martin Stone Davis <[EMAIL PROTECTED]> wrote:
> > > In any case, I think this thread is complete... Toad's premix routing
> > > solution (when he's able to get to it) will solve the anonymit
You are suggesting that specailization makes no sense in small
networks and that freenet does what is optimal. Ian, please think
about this. In a tiny network were every node was connected to every
other one, specialization still makes sense.
Optimally each node would be specialized in a portion
--- Toad <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 27, 2003 at 01:54:16PM +0100, Some Guy wrote:
> > --- Nick Tarleton <[EMAIL PROTECTED]> wrote:
> > > I have heard a lot about Freenet's emergent behavior and would like to
> > > understand just what mechanisms in the code make this happen.
> >
> What prevents a query from bouncing back through our node?
> Seems like if left unchecked, we could have traffic that just
> loops aruond in small circles eating bandwidth and not being
> productive?
Each message has an ID.. This ID is remebered by the node for some time
and the memory is us
--- Ian Clarke <[EMAIL PROTECTED]> wrote:
> Tracy R Reed wrote:
> > Yes, I agree. However I am concerned that I am not even seeing signs of
> > recovery 48 hours later. The network cannot take that long to converge if
> > it is converging at all.
>
> The network will only converge when this beco
> > > Connection attempts 1193
> > > Connection successes 1047
> > > Consecutive failed connections 0
> > > Probability of connection failure 0.017196883744822623
> >
> > Umm, why is this bad?
>
> On my node, connectingTime is in the 10s range. The above
> was doing 1 a second. If connectio
How about releasing a stable build 5029 that does not talk to those rogue
anti-NGR nodes (6163 <= build number <= 6279)?! (I'm tired of blocking
those in my routing table with my firewall.)
Unfortunately the routing algorithm of the stable nodes can't work around
those evil nodes.
jnk
--
my pen
1 - 100 of 111 matches
Mail list logo
