From: Ian Clarke <[EMAIL PROTECTED]>
> By now we are all painfully aware of the very correct observation that
there can be no reliably enforceable negative trust on the Internet.
Unfortunately, those that insist on repeating this fact over and over
again fail to see that even though negative tru
Tom Kaitchuck wrote:
On Monday 10 November 2003 04:19 pm, Ken Corson wrote:
Tom-
If I follow you correctly, you are saying that a node may choose to
slant it's bandwidth usage in favor of sending queries on behalf of
the local node, and disfavor the service of data transfer to others.
If a node
Tom Kaitchuck wrote:
OK, Here is a possible solution that addresses most of the current issues we
are currently seeing.
requests out of both ends of the queue. One end is a LIFO. This would be the
default end. When a new thread becomes available, it grabs a request from
this end and removes it
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node
Modified Files:
Tag: stable
ConnectionOpener.java FailureTable.java Main.java Node.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} ite
Freenet stable build 5032 is now available. Use your update utility to
upgrade (freenet-webinstall.exe or update.sh depending on platform). It
is also available from
http://freenetproject.org/snapshots/freenet-latest.jar (stop your node,
install this over your current freenet.jar, start your node)
On Monday 10 November 2003 04:19 pm, Ken Corson wrote:
> Tom-
>If I follow you correctly, you are saying that a node may choose to
> slant it's bandwidth usage in favor of sending queries on behalf of
> the local node, and disfavor the service of data transfer to others.
> If a node sets rtMaxN
On Monday 10 November 2003 03:16 pm, Ken Corson wrote:
> Ian Clarke wrote:
> > One very-easily implemented approach might be to not route to a node for
> > a period of time after a QR. If the node then QRs again, we wait twice
> > as long (ie. an exponential backoff). We had something like this i
Update of /cvsroot/freenet/freenet/src/freenet/node/states/data
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node/states/data
Modified Files:
Tag: stable
SendData.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node/states/request
Modified Files:
Tag: stable
RequestState.java DataPending.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key
Update of /cvsroot/freenet/freenet/src/freenet/support/graph
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/support/graph
Modified Files:
Tag: stable
Bitmap.java Color.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet
Modified Files:
Tag: stable
Version.java PeerPacketMessage.java Key.java PeerHandler.java
Core.java OpenConnectionManager.java ConnectionHandler.java
Log Message:
5032:
Ma
Update of /cvsroot/freenet/freenet/src/freenet/node/http/infolets
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node/http/infolets
Modified Files:
Tag: stable
GeneralInfolet.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separatel
Update of /cvsroot/freenet/freenet/src/freenet/support/servlet/http
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/support/servlet/http
Modified Files:
Tag: stable
HttpServletRequestImpl.java HttpSupport.java
Log Message:
5032:
Major changes to failure table
Track {HT
Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcing
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node/states/announcing
Modified Files:
Tag: stable
ExecuteAnnouncement.java Announcing.java AnnouncingState.java
SendAnnouncement.java CompleteAnnoun
Update of /cvsroot/freenet/freenet/src/freenet/support/test
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/support/test
Modified Files:
Tag: stable
URLDecoderTest.java KeyTest.java RedBlackTreeTest.java
SkiplistTest.java
Log Message:
5032:
Major changes to failure
Update of /cvsroot/freenet/freenet/src
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src
Modified Files:
Tag: stable
Makefile.gcj
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be more than one per key. Should
increase FT effecti
Update of /cvsroot/freenet/freenet/src/freenet/thread
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/thread
Modified Files:
Tag: stable
YThreadFactory.java FastThreadFactory.java ThreadFactory.java
QThreadFactory.java
Log Message:
5032:
Major changes to failure tab
Update of /cvsroot/freenet/freenet/src/freenet/message/client/FEC
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/message/client/FEC
Modified Files:
Tag: stable
FECMakeMetadata.java FECSegmentSplitFile.java BlockMap.java
SegmentHeader.java FECSegmentFile.java
Log Me
Update of /cvsroot/freenet/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv16000
Modified Files:
Tag: stable
Makefile
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be more than one per key. Should
increase FT effectiveness.
Update of /cvsroot/freenet/freenet/src/freenet/support
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/support
Modified Files:
Tag: stable
RandomAccessFilePool.java
Added Files:
Tag: stable
FakeRandomAccessFilePool.java RealRandomAccessFilePool.java
Log Messag
Update of /cvsroot/freenet/freenet/src/freenet/fs/dir
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/fs/dir
Modified Files:
Tag: stable
NativeFSDirectory.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be more than
Update of /cvsroot/freenet/freenet/src/freenet/client
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/client
Modified Files:
Tag: stable
InternalClient.java AutoRequester.java ClientCore.java
VirtualClient.java
Log Message:
5032:
Major changes to failure table
Update of /cvsroot/freenet/freenet/src/freenet/interfaces
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/interfaces
Modified Files:
Tag: stable
BaseLocalNIOInterface.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can b
Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcement
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node/states/announcement
Modified Files:
Tag: stable
NewAnnouncement.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} it
Update of /cvsroot/freenet/freenet/src/freenet/support/servlet
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/support/servlet
Modified Files:
Tag: stable
ServletResponseImpl.java ServletContextImpl.java
Log Message:
5032:
Major changes to failure table
Track {HTL, tim
Update of /cvsroot/freenet/freenet/src/freenet/config
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/config
Modified Files:
Tag: stable
Config.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be more than one per key
Update of /cvsroot/freenet/freenet/src/freenet/client/http
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/client/http
Modified Files:
Tag: stable
NodeStatusServlet.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv16000/src/freenet/node/states/FNP
Modified Files:
Tag: stable
NewRequest.java
Log Message:
5032:
Major changes to failure table
Track {HTL, time, key} items separately - can be
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv14014/src/freenet/node/rt
Modified Files:
StandardNodeEstimator.java
Log Message:
6324:
Don't substitute pLegitDNF for pDNF when pDNF is 0.0, for 2 reasons: 1. FP == is
unreliable. 2. Only reason
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv14014/src/freenet
Modified Files:
Version.java PeerPacketMessage.java
Log Message:
6324:
Don't substitute pLegitDNF for pDNF when pDNF is 0.0, for 2 reasons: 1. FP == is
unreliable. 2. Only reason it wou
Yeah, it could be accounted for... meh...
On Mon, 11/10/03 at 20:49:59 -0500, Ken Corson wrote:
> Brandon Low wrote:
> >On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
> >
> >>Brandon Low wrote:
> >>
> >>>Absolutely NOT, if node A waits for it's next request until it gets a
> >>>response to
On November 10, 2003 08:13 pm, Brandon Low wrote:
> On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
>
> > Brandon Low wrote:
> >
> > > Freenet
> > >doesn't work this way, watch this:
> > >
> > >Node A wants something from Node B.
> > >A sends a request to B
> > >A replies and says "wait X"
>
Brandon Low wrote:
On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
Brandon Low wrote:
Absolutely NOT, if node A waits for it's next request until it gets a
response to it's first request, we have just gone to a protocol with
worse problems than TCP w/o tcp transmit windows. This would caus
On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
> Brandon Low wrote:
> >Absolutely NOT, if node A waits for it's next request until it gets a
> >response to it's first request, we have just gone to a protocol with
> >worse problems than TCP w/o tcp transmit windows. This would cause
> >nodes
Brandon Low wrote:
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
Brandon Low wrote:
Freenet
doesn't work this way, watch this:
Node A wants something from Node B.
A sends a request to B
A replies and says "wait X"
B says to itself "OK, I'll wait X"
No, A sends a request to B. B eventually
Ian Clarke wrote:
Ed Tomlinson wrote:
What Ken suggested is that B remember what it told A and should not
respond to A at all if it routes early - this forces A to wait for a
timeout... It also helps to perserve the outgoing bandwidth.
Well, I think that is too forgiving. If A routes early the
I will now merge the current 6323 (plus the recent improvement in RT
sorting) to stable. After that, we will see if the recent changes have
made much difference, and implement exponential backoff on
QueryRejected's, a strategy very similar to what we used during the
supposed golden age, which is si
- Original Message -
From:
Ian Clarke
To: Discussion of development issues
Sent: Monday, November 10, 2003 1:06
PM
Subject: [freenet-dev] More musings on
NGR and load-balancing
The more I think about it, the more I think that putting NGR in-charge
of l
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
> Brandon Low wrote:
> > Freenet
> >doesn't work this way, watch this:
> >
> >Node A wants something from Node B.
> >A sends a request to B
> >A replies and says "wait X"
> >B says to itself "OK, I'll wait X"
>
> No, A sends a request to B. B
Ed Tomlinson wrote:
What Ken suggested is that B remember what it told A and
should not respond to A at all if it routes early - this forces A
to wait for a timeout... It also helps to perserve the outgoing
bandwidth.
Well, I think that is too forgiving. If A routes early then it is
knowingly
Brandon Low wrote:
How? Any node which sends another request before X has elapsed gets
banned?
Well, X is node specific, so any node which sends a request before *its*
X has elapsed is clearly not following the rules and should be banned.
Any node which sends more than 2 before X has elapsed?
We
OK, I think I've found a few errors in how NGrouting operates. Please note
that anything I say here takes precedence over my previous message. Also
could someone please check all of this. I can't verify my own sanity :)
First, very minor:
line 643 of /node/rt/ResponceTimeEstimator
if ((
You and edt win. If we just drop requests on the floor that go over
what we are allowing from another node, it only hurts the requesting
node ont to listen.
The synchronization/network latency issues would be pretty hard to
overcome, how for instance would a timing based approach like this
handle
I've noticed that snapshots are often not updated over the weekend, and
there may be a good practical reason for this: however, up to now
(Monday, 23.08UTC), the unstable latest snapshot has not been updated to
6323.
--
Roger Hayter
___
Devl mailing li
Tom Kaitchuck wrote:
On Monday 10 November 2003 10:49 am, Martin Stone Davis wrote:
Tom Kaitchuck wrote:
Please read my message where I bitch about the doctor's office alalogy.
Bottom line: We are NOT trying to prevent any from making as many
requests as they like on the network. We ARE trying to p
Brandon Low wrote:
How? Any node which sends another request before X has elapsed gets
banned? Any node which sends more than 2 before X has elapsed? Freenet
Any solution which you find to this will rely on properly behaving other
nodes, and cannot be solved by banning misbehavers.
I respectful
Actually Ken mentioned a good idea. Try this for size
Node A want something from B
A send request to B
B QRs to A saying wait for X
at this point several things can happen
A waits for X before routing to B again
or
A ignores the wait and routes to B when it wants to
What Ken suggested is that B
>Ian Clarke wrote:
>
>> Martin Stone Davis wrote:
>>
1) Given the difficulty of circumventing negative trust will users
actually be bothered to do it?
>>> It wouldn't be so difficult if someone else had already gone through
>>> the trouble of creating and distributing SuperFreenet
Ian Clarke wrote:
Ok, we forget about quotas, nice, but overcomplicated.
We add a "don't send a request to me more often than X milliseconds"
field to a few messages sent in response to requests.
Two options about how to calculate X:
1) Empirical
We calculate X to be ((60*60*1000) / M) / T
2) E
Brandon Low wrote:
Ahh, but look at your send queue... there isn't so much a performance
increase as a decrease in QRing and a decrease in BW-per-transfer.
You say tomaeto, I say tomahto ... you're a pragmatist, Brandon :)
As am I - certainly not an optimist, hopefully not a pessimist.
Thank you fo
How? Any node which sends another request before X has elapsed gets
banned? Any node which sends more than 2 before X has elapsed? Freenet
doesn't work this way, watch this:
Node A wants something from Node B.
A sends a request to B
A replies and says "wait X"
B says to itself "OK, I'll wait X"
Ian Clarke wrote:
One very-easily implemented approach might be to not route to a node for
a period of time after a QR. If the node then QRs again, we wait twice
as long (ie. an exponential backoff). We had something like this in the
old days. Of course, if this doesn't work we should go back
On November 10, 2003 11:09 am, Christopher Hotchkiss wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> It doesn't seem that unreasonable, I continuously have amounts in the 35MBi
> range waiting to be transfered. So if you just turned your node on, its to
> be expected.
Figure out how
On Monday 10 November 2003 10:49 am, Martin Stone Davis wrote:
> Tom Kaitchuck wrote:
> > Please read my message where I bitch about the doctor's office alalogy.
> > Bottom line: We are NOT trying to prevent any from making as many
> > requests as they like on the network. We ARE trying to prevent
Ian Clarke wrote:
making our users continue to suffer from the lack of an effective load
balancing mechanism?
Just so that we are all on the same page, we should clarify our
definition of load-balancing. I believe there are two components
to this definition -
1) query traffic versus data traffic n
On Saturday 08 November 2003 06:38 am, Ian Clarke wrote:
> Tom Kaitchuck wrote:
> > OK, so I've finally gotten around to looking at the NGrouting source, and
> > I have a few questions. Which are hopefully simple to answer.
> >
> > First in node/rt/StandardNodeEstimator.java on line 162 ish there i
Brandon Low wrote:
Thought: It would be easy for some asstard (me) to write a client that
completely disregards these "wait" messages and therefore gets
performance, and market it as 'Freenet-Xtreme' or some damned thing.
We have already been through this a thousand times.
If someone did do this
Thought: It would be easy for some asstard (me) to write a client that
completely disregards these "wait" messages and therefore gets
performance, and market it as 'Freenet-Xtreme' or some damned thing.
--B
On Mon, 11/10/03 at 19:44:47 +, Ian Clarke wrote:
> Ok, we forget about quotas, nice,
Ok, we forget about quotas, nice, but overcomplicated.
We add a "don't send a request to me more often than X milliseconds"
field to a few messages sent in response to requests.
Two options about how to calculate X:
1) Empirical
We calculate X to be ((60*60*1000) / M) / T
2) Experimental
We sta
Martin Stone Davis wrote:
If so, doesn't this allow for a really easy DoS attack? Wouldn't a
malicious node only have to use a small portion of bandwidth to exceed
his allocation and halt queries for everyone else?
Yes, but DoS attacks are already easy, so adding a new way to do them
does't rea
Martin Stone Davis wrote:
But, shouldn't we *first* consider ideas which won't have these
additional vulnerabilities? My "public quotas" idea (which is a
modification of your quota idea) is an example. I think it might solve
the problem, and I haven't heard any response to that idea.
What was
Ian Clarke wrote:
Toad wrote:
On Mon, Nov 10, 2003 at 06:04:44PM +, Ian Clarke wrote:
What happens if somebody comes to us with a feature gift of an IPv6
transport and the infrastructure to use multiple transports? Unless we
have this conversation now we'd probably accept it.
Ok, so your ar
On Mon, 11/10/03 at 18:12:03 +, Toad wrote:
> On Sun, Nov 09, 2003 at 12:33:48PM -0800, Brandon Low wrote:
> > Update of /cvsroot/freenet/freenet/src/freenet/node/rt
> > In directory sc8-pr-cvs1:/tmp/cvs-serv21891/freenet/src/freenet/node/rt
> >
> > Modified Files:
> > NGRoutingTable.java
Ahh, but look at your send queue... there isn't so much a performance
increase as a decrease in QRing and a decrease in BW-per-transfer.
--Brandon
On Mon, 11/10/03 at 10:15:58 -0800, Salah Coronya wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I've been running 6323 (compiled from
Toad wrote:
On Mon, Nov 10, 2003 at 06:04:44PM +, Ian Clarke wrote:
What happens if somebody comes to us with a feature gift of an IPv6
transport and the infrastructure to use multiple transports? Unless we
have this conversation now we'd probably accept it.
Ok, so your argument is that Freenet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been running 6323 (compiled from CVS), for 15 1/2
hours and my node
seems to be processing a lot more requests:
Histogram of requested keys.
This count has nothing to do with keys in your
datastore
Nov 10, 2003 12:07:57 PM
keys: 198031
Histogram
On Mon, Nov 10, 2003 at 06:04:44PM +, Ian Clarke wrote:
> Toad wrote:
> >>No, I'm a Java API newbie. I was just trying to say in a short-handed
> >>fashion that someone could create some sort of executable to get around
> >>the difficulty... then all the newbies like me could easily cheat.
>
On Sun, Nov 09, 2003 at 12:33:48PM -0800, Brandon Low wrote:
> Update of /cvsroot/freenet/freenet/src/freenet/node/rt
> In directory sc8-pr-cvs1:/tmp/cvs-serv21891/freenet/src/freenet/node/rt
>
> Modified Files:
> NGRoutingTable.java
> Log Message:
> Change how rt nodes are removed from the
The more I think about it, the more I think that putting NGR in-charge
of load balancing is like putting the wolf in-charge of the sheep (or,
perhaps a more apt analogy, putting a capitalist in-charge of the
environment).
The problem is that NGR relies on the notion that what is good for the
i
Toad wrote:
No, I'm a Java API newbie. I was just trying to say in a short-handed
fashion that someone could create some sort of executable to get around
the difficulty... then all the newbies like me could easily cheat.
Well, one point: We will have to prohibit IPv6 on the network, because
IPv6
On Mon, Nov 10, 2003 at 09:58:12AM -0800, Martin Stone Davis wrote:
> Ian Clarke wrote:
>
> >Martin Stone Davis wrote:
> >
> >>>1) Given the difficulty of circumventing negative trust will users
> >>>actually be bothered to do it?
> >>>
> >>It wouldn't be so difficult if someone else had already
Ian Clarke wrote:
Martin Stone Davis wrote:
1) Given the difficulty of circumventing negative trust will users
actually be bothered to do it?
It wouldn't be so difficult if someone else had already gone through
the trouble of creating and distributing SuperFreenet.jar.
How would SuperFreenet
Toad wrote:
Okay, who wants to run the central server? We can solve all freenet's
performance problems by reimplementing Kazaa and ignoring the
theoretical issues concerning anonymity. :)
Thanks, very helpful suggestion :-)
Ian.
___
Devl mailing list
[EM
> > While people navel-gaze over theoretical issues the network is barely
> > working due to these load-balancing problems. I would rather have an
> > imperfect solution now than a perfect solution later.
>
> Okay, who wants to run the central server? We can solve all freenet's
> performance prob
On Mon, Nov 10, 2003 at 05:29:29PM +, Ian Clarke wrote:
> Martin Stone Davis wrote:
> >>1) Given the difficulty of circumventing negative trust will users
> >>actually be bothered to do it?
> >>
> >It wouldn't be so difficult if someone else had already gone through the
> >trouble of creating
Martin Stone Davis wrote:
1) Given the difficulty of circumventing negative trust will users
actually be bothered to do it?
It wouldn't be so difficult if someone else had already gone through the
trouble of creating and distributing SuperFreenet.jar.
How would SuperFreenet.jar manage to run a F
Ian Clarke wrote:
By now we are all painfully aware of the very correct observation that
there can be no reliably enforceable negative trust on the Internet.
Unfortunately, those that insist on repeating this fact over and over
again fail to see that even though negative trust cannot be enforced
By now we are all painfully aware of the very correct observation that
there can be no reliably enforceable negative trust on the Internet.
Unfortunately, those that insist on repeating this fact over and over
again fail to see that even though negative trust cannot be enforced
against someone
Tom Kaitchuck wrote:
On Monday 10 November 2003 05:03 am, Ken Corson wrote:
Martin Stone Davis wrote:
Tom Kaitchuck wrote:
OK, Here is a possible solution that addresses most of the current
issues we are currently seeing.
Before anyone yells "It can't work! An operator could just create
hundreds
On Monday 10 November 2003 05:03 am, Ken Corson wrote:
> Martin Stone Davis wrote:
> > Tom Kaitchuck wrote:
> >> OK, Here is a possible solution that addresses most of the current
> >> issues we are currently seeing.
> >
> > Before anyone yells "It can't work! An operator could just create
> > hund
On Monday 10 November 2003 01:02 am, Ken Corson wrote:
> Jon:
> on a more serious note, how do you know the upstream node is in any
> better condition to handle the request ? this seems like avoiding
> our local responsibility... i suppose it is fair to say, if a node
> doesn't reject a request, th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It doesn't seem that unreasonable, I continuously have amounts in the 35MBi
range waiting to be transfered. So if you just turned your node on, its to
be expected.
On Monday 10 November 2003 05:42 am, Ken Corson wrote:
> Ed Tomlinson wrote:
> > H
Martin Stone Davis wrote:
Tom Kaitchuck wrote:
OK, Here is a possible solution that addresses most of the current
issues we are currently seeing.
Before anyone yells "It can't work! An operator could just create
hundreds of nodes!" I just want to mention that the easy way around that
is to mak
Ed Tomlinson wrote:
Hi,
Am I the only one seeing insane send queue numbers? Here looking in
the OCM (advanced mode/Open Connections) I see 272 connections
transmitting with a queue of 130M! I have a 10K output limit...
Ed, double check that you are reading the labels correctly - the
positio
Martin Stone Davis wrote:
Ian Clarke wrote:
A node would therefore know, for all of its references, how many
requests it is permitted to send (within a time-period) and NGR could
even take account of that information in some way, although that is
probably over-ambitious for an initial implementatio
Ed Tomlinson wrote:
On the otherhand, maybe we want to just eliminate QR and use something
like this. Nodes have 100ms to reply with a Query Accepted otherwise the
query is deemed to have been rejected. NG should be more that able to
Ed, this is a feasible solution in certain environments. Howe
Update of /cvsroot/freenet/freenet/src/freenet/support
In directory sc8-pr-cvs1:/tmp/cvs-serv10578/support
Modified Files:
RandomAccessFilePool.java
Added Files:
FakeRandomAccessFilePool.java RealRandomAccessFilePool.java
Log Message:
Cleanup descriptions shown by --config
setExp
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv10578/node
Modified Files:
Node.java
Log Message:
Cleanup descriptions shown by --config
setExpert on three options someone added without descriptions.
Fix an NPE in the old RandomAccessFilePool
Reim
Update of /cvsroot/freenet/freenet/src/freenet/config
In directory sc8-pr-cvs1:/tmp/cvs-serv10578/config
Modified Files:
Config.java
Log Message:
Cleanup descriptions shown by --config
setExpert on three options someone added without descriptions.
Fix an NPE in the old RandomAccessFilePoo
Update of /cvsroot/freenet/freenet/src/freenet/fs/dir
In directory sc8-pr-cvs1:/tmp/cvs-serv10578/fs/dir
Modified Files:
NativeFSDirectory.java
Log Message:
Cleanup descriptions shown by --config
setExpert on three options someone added without descriptions.
Fix an NPE in the old RandomAc
Jusa Saari wrote:
If I understood correctly, then currently, when a node queryrejects, the
QR goes back in line to the node that originated the request, and that
node will then send it to a different node. If this is true, then it has
the potential to royally mess up the network.
- no, you are conf
Andrew Rodland wrote:
I'm running 6233, and just thought I'd report a few statistics of interest.
First, searchFailedCount is down to between 2 and 3, rather than between 3
I had a real good day yesterday running 6322 here. Practically no QR!
So I better take a picture while I can. Look at this. U
Toad wrote:
On Fri, Nov 07, 2003 at 10:29:45PM -0500, Zlatin Balevsky wrote:
Toad wrote:
One radical solution:
Remove the code to reject queries when the bandwidth limit is exceeded!
which returns us in the state 5010-5018 where the node has accepted
umpteen transfers, each going at snail speed.
Jon Brock wrote:
Another idea is to have a queue, and give priority to requests that are closer
to one of the node's specialization areas. If all bandwidth is used up, but a
new request comes in for a key that we have and is in our specialization, pause
the most irrelevant transfer for a while and
Martin Stone Davis wrote:
Let me use a biological analogy: Say your goal is to have a whole bunch
of babies (don't ask my why you'd want this). Also, say you're a woman
from another planet (say, Mars), and you can actually get pregnant while
you're pregnant. However, you can't have more than a
95 matches
Mail list logo
