Martin Stone Davis wrote:
I think you're jumping ahead a little too quick. We haven't even seen
the potential of QR backoff yet because we haven't upped lastGoodBuild
and lots of queries *seem* (Ken?) to be coming from older nodes. That
in itself should reduce the number of QRs dramatically.
I recently started a new node.. After about 4 hrs of uptime it had
downloaded about 100 meg data and had accumulated around 290 keys in the
store... Then I restarted the node and when it came up again the ds was
reported as containing only 37 meg of data and 160 keys...
Any idea why this
Update of /cvsroot/freenet/freenet/src/freenet/support/servlet/http
In directory sc8-pr-cvs1:/tmp/cvs-serv17801
Modified Files:
HttpSupport.java
Log Message:
Fix exception in parseCookie:
java.lang.StringIndexOutOfBoundsException: String index out of range
Couldn't test this because I
Ian Clarke [EMAIL PROTECTED] writes:
Toad wrote:
Is there any reason not to keep the backoff data when a node is dropped
from the routing table?
Provided we delete it sometime, probably not.
Ian.
Why stop at just keeping backoff data? Keep routing information to
nodes we aren't
Toad [EMAIL PROTECTED] writes:
I do now. However, it is a way that a node could hurt the network
without being proportionately punished for it in the estimators - if I
reinstate it, then nodes that QR with HTL 0, killing the request, will be
treated the same as nodes that QR at any other HTL.
Whops.. I did it again.
Before restart: 592 megs in 3764 keys in the ds
After restart: 488 megs in 1345 keys in the ds
The numbers above are from the enironment page. The next time I restart I'll
try to have a look at the actual number of files in the store before I
restart (the numbers after
On Thu, Nov 20, 2003 at 12:13:17PM -0600, Edgar Friendly wrote:
Ian Clarke [EMAIL PROTECTED] writes:
Toad wrote:
Is there any reason not to keep the backoff data when a node is dropped
from the routing table?
Provided we delete it sometime, probably not.
Ian.
Why stop
On Thu, Nov 20, 2003 at 10:11:52PM +0100, Niklas Bergh wrote:
Whops.. I did it again.
Before restart: 592 megs in 3764 keys in the ds
After restart: 488 megs in 1345 keys in the ds
The numbers above are from the enironment page. The next time I restart I'll
try to have a look at the
Before restart: 592 megs in 3764 keys in the ds
After restart: 488 megs in 1345 keys in the ds
The numbers above are from the enironment page. The next time I restart
I'll
try to have a look at the actual number of files in the store before I
restart (the numbers after the restart seems
Update of /cvsroot/freenet/freenet/src/freenet/interfaces
In directory sc8-pr-cvs1:/tmp/cvs-serv24137/src/freenet/interfaces
Modified Files:
FreenetConnectionRunner.java
Log Message:
6343:
Logging.
Catch and log throwables caught starting up interfaces, rather than killing ALL
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv24137/src/freenet/node
Modified Files:
Main.java
Log Message:
6343:
Logging.
Catch and log throwables caught starting up interfaces, rather than killing ALL
interfaces when one throws.
Add new
Update of /cvsroot/freenet/freenet/src/freenet/node/states/data
In directory sc8-pr-cvs1:/tmp/cvs-serv24137/src/freenet/node/states/data
Modified Files:
SendData.java
Log Message:
6343:
Logging.
Catch and log throwables caught starting up interfaces, rather than killing ALL
interfaces
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv24137/src/freenet
Modified Files:
Version.java Core.java ConnectionHandler.java
OpenConnectionManager.java
Log Message:
6343:
Logging.
Catch and log throwables caught starting up interfaces,
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv24137/src/freenet/node/states/request
Modified Files:
ReceivingInsert.java SendingReply.java
Log Message:
6343:
Logging.
Catch and log throwables caught starting up interfaces, rather
Update of /cvsroot/freenet/freenet/src/freenet/node/states/data
In directory sc8-pr-cvs1:/tmp/cvs-serv1585/src/freenet/node/states/data
Modified Files:
SendData.java
Log Message:
6344:
Even more stats.
Even more logging.
Catch some corner cases in .received(DataReceived)'s.
Ignore a
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv1585/src/freenet/node/states/request
Modified Files:
TransferReply.java TransferInsert.java
Log Message:
6344:
Even more stats.
Even more logging.
Catch some corner cases in
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv1585/src/freenet/node
Modified Files:
Main.java
Log Message:
6344:
Even more stats.
Even more logging.
Catch some corner cases in .received(DataReceived)'s.
Ignore a double abort in SendData.
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv1585/src/freenet
Modified Files:
Version.java
Log Message:
6344:
Even more stats.
Even more logging.
Catch some corner cases in .received(DataReceived)'s.
Ignore a double abort in SendData.
Index:
On Fri, Nov 21, 2003 at 12:04:09AM +0100, Niklas Bergh wrote:
Before restart: 592 megs in 3764 keys in the ds
After restart: 488 megs in 1345 keys in the ds
The numbers above are from the enironment page. The next time I restart
I'll
try to have a look at the actual number of files in
On Tuesday 18 November 2003 06:41 am, Edward J. Huff wrote:
Well, what I want to do is to allow the node to be in control of
the backoff time, as follows:
When a fluctuation of the success rate results in excess trailers,
the node estimates how long they will take to transmit. Then it
On Thu, Nov 20, 2003 at 11:58:45AM -0600, Edgar Friendly wrote:
Toad [EMAIL PROTECTED] writes:
I do now. However, it is a way that a node could hurt the network
without being proportionately punished for it in the estimators - if I
reinstate it, then nodes that QR with HTL 0, killing the
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv4920/src/freenet
Modified Files:
Version.java
Log Message:
6345:
Use the HTL from the QueryRejected.
This allows a node to kill requests without any impact in its long term estimators,
but we backoff on
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv4920/src/freenet/node/states/request
Modified Files:
Pending.java
Log Message:
6345:
Use the HTL from the QueryRejected.
This allows a node to kill requests without any impact in its
Unstable 6345 is in CVS and will soon be in the unstable snapshot jar.
The main change is the reinstatement of the code to use the HTL value
from a QueryRejected. This is because sometimes when we get a
QueryRejected, it is because the node sent a query to several nodes and
they all rejected it.
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv6962/src/freenet/node/states/FNP
Modified Files:
NewRequest.java
Log Message:
6346: KenMan's patch: Add version to nodes in inboundRequests.txt.
Index: NewRequest.java
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv6962/src/freenet/node
Modified Files:
Node.java
Log Message:
6346: KenMan's patch: Add version to nodes in inboundRequests.txt.
Index: Node.java
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv6962/src/freenet
Modified Files:
Version.java ContactCounter.java
Log Message:
6346: KenMan's patch: Add version to nodes in inboundRequests.txt.
Index: Version.java
Update of /cvsroot/freenet/freenet/src/freenet/client/http
In directory sc8-pr-cvs1:/tmp/cvs-serv6962/src/freenet/client/http
Modified Files:
NodeStatusServlet.java
Log Message:
6346: KenMan's patch: Add version to nodes in inboundRequests.txt.
Index: NodeStatusServlet.java
Update of /cvsroot/freenet/freenet/src/freenet/node/states/announcement
In directory sc8-pr-cvs1:/tmp/cvs-serv6962/src/freenet/node/states/announcement
Modified Files:
NewAnnouncement.java
Log Message:
6346: KenMan's patch: Add version to nodes in inboundRequests.txt.
Index:
Toad wrote:
On Wed, Nov 19, 2003 at 04:20:15AM -0800, Martin Stone Davis wrote:
Ian Clarke wrote:
Niklas Bergh wrote:
NGR is designed to take into account a nodes available bw and include
that fact in routing decisions. Instead of overloading an already
overloaded (bw-wise) node even more NGR
Ken Corson wrote:
trouble. Currently, in my routing table , a significant portion of
my routes are backed off for more than 100 seconds. There probably
This alone should remind people of the last problem we faced.
Namely, that it took several outbound query attempts until
it finally got accepted
Ian Clarke wrote:
Toad wrote:
Is there any reason not to keep the backoff data when a node is dropped
from the routing table?
Provided we delete it sometime, probably not.
Yes, there is. Given that it is a completely transient condition, why
would we want to remember this unpleasant experience ?
Edward J. Huff wrote:
On Wed, 2003-11-19 at 17:21, Ian Clarke wrote:
Toad wrote:
Is there any reason not to keep the backoff data when a node is dropped
from the routing table?
Provided we delete it sometime, probably not.
It seems to me that there is some reasonable maximum backoff period.
For
On Tuesday 18 November 2003 06:41 am, Edward J. Huff wrote:
Well, what I want to do is to allow the node to be in control of
the backoff time, as follows:
Can anyone explain how this protocol is vulnerable to attack?
Tom Kaitchuck wrote:
(Sometimes it's worth while to try a node even if it is
Toad wrote:
On Thu, Nov 20, 2003 at 11:58:45AM -0600, Edgar Friendly wrote:
Toad [EMAIL PROTECTED] writes:
I do now. However, it is a way that a node could hurt the network
without being proportionately punished for it in the estimators - if I
reinstate it, then nodes that QR with HTL 0, killing
Bottom line: When the expected time to complete a transfer
is larger than the expected time before the node is taken
down, then that node could just as well stay down permanently.
All of the output bandwidth it is consuming is going to be
wasted when none of the zillion transfers finish.
I think
Ed Tomlinson wrote:
On November 18, 2003 10:06 pm, Toad wrote:
On Tue, Nov 18, 2003 at 09:55:54PM -0500, Ed Tomlinson wrote:
On November 18, 2003 09:48 pm, Toad wrote:
On Tue, Nov 18, 2003 at 09:47:03PM -0500, Ed Tomlinson wrote:
On November 18, 2003 05:29 pm, Toad wrote:
On Tue, Nov 18, 2003 at
37 matches
Mail list logo
