On Wed, Nov 19, 2003 at 01:36:43AM +, Toad wrote:
Freenet stable build 5038 is now available. Upgrade using update.sh or
freenet-webinstall.exe, or get the jar from
http://freenetproject.org/snapshots/freenet.jar
^^^
ERROR 404: Not Found
Maybe
I think freenet is suffering because it doesn't have key space
specialisation. NGR is trying to route quickly, all un-overload are
quick, get the traffic, route to each other, overload, etc.
If this is the case we should try to reduce QRs as much as possible -
remove QR based on
Niklas Bergh wrote:
I think freenet is suffering because it doesn't have key space
specialisation. NGR is trying to route quickly, all un-overload are
quick, get the traffic, route to each other, overload, etc.
If this is the case we should try to reduce QRs as much as possible -
remove QR based
Niklas Bergh wrote:
I think freenet is suffering because it doesn't have key space
specialisation. NGR is trying to route quickly, all
un-overload are
quick, get the traffic, route to each other, overload, etc.
If this is the case we should try to reduce QRs as much as
possible -
Toad wrote:
On Tue, Nov 18, 2003 at 03:46:19PM -0800, Martin Stone Davis wrote:
Toad wrote:
On Tue, Nov 18, 2003 at 11:00:27PM +0100, Thomas Themel wrote:
Hi,
my node is currently running off an ISDN link, and it seems to build up
pretty high values in the connection manager's 'Data
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv24146/src/freenet
Modified Files:
OpenConnectionManager.java ConnectionHandler.java
Log Message:
Display descriptions of connection state instead of negative numbers when connection
is in process of
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 would be sending the Q to
another node.
A bw-caused QR will completely hide the actual bw problem from
Hi all:
I'm running 5038. The problem indicated below generally crops up after a
few hours of running my node, it's been taking place for the last few
builds. Everything runs just fine for a few hours, then all of a sudden,
the number of threads skyrockets out of control until Freenet (or
--- Tracy R Reed [EMAIL PROTECTED] wrote:
On Tue, Nov 18, 2003 at 09:18:51PM +, Jonathan Howard spake thusly:
speed. Don't know how to kick start it out of the current state though.
The only other way I can think of at the moment is nodes having
(semi)strict self key space
Running node 6340
Connections open (Inbound/Outbound/Limit) 1023 (593/430/1024)
Connections transferring (Transmitting/Receiving) 394 (377/17)
Data waiting to be transfered 270 MiB
Total amount of data transferred1,268 MiB
That's a lot of
Hi,
Ed Tomlinson ([EMAIL PROTECTED]) wrote on 2003-11-19:
Problem is that all the flies can enter the swamp but they can only leave
through a couple small tubes. The flies breed and the frogs and fish cannot
eat them fast enough so lots of them queue at the exit tubes.
I don't quite get the
On a related note, I'm thinking of moving the node to a DSL
uplink for the rest of the month (I've only got 20GB to waste
per month on the DSL link, and that takes my node about 10
days). Does anyone care to predict whether it will adjust to
the new situation quickly enough for the speed
On November 19, 2003 07:44 am, Ed Tomlinson wrote:
On November 19, 2003 03:51 am, Niklas Bergh wrote:
On November 18, 2003 08:52 am, Martin Stone Davis wrote:
We already back-off due to QR, so we already have a way of telling
when every node is going to be ready. The issue here is
I prefer m0davis method since it matches up better with NGR. NGR
learns times needed.. Not the ugly QR binary on/off stuff.
As I stated
in another mail.. NGR indeed seems to be able to (as it is
intendedc
to) utilize time consumed for different tasks to do a
better job while
it
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 would
On Wed, Nov 19, 2003 at 02:22:26PM +0100, Thomas Themel wrote:
Hi,
Ed Tomlinson ([EMAIL PROTECTED]) wrote on 2003-11-19:
Problem is that all the flies can enter the swamp but they can only leave
through a couple small tubes. The flies breed and the frogs and fish cannot
eat them fast
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv32147/src/freenet
Modified Files:
Tag: stable
Version.java
Log Message:
5039: Redisable QR on bandwidth. Was an experiment, looks like routing will work
better without it.
Index: Version.java
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv32717/src/freenet/node
Modified Files:
Tag: stable
Node.java
Log Message:
D'oh.
Index: Node.java
===
RCS file:
Try setting threadFactory=Y in freenet.conf or wherever it is in
Windows. YThreadFactory was designed to avoid exactly this problem.
Be sure to remove the % from the front of the line.
This helps only if those threads would have exited quickly if you
had lots more physical memory than you have.
On Monday 17 November 2003 07:37 pm, Toad wrote:
On Mon, Nov 17, 2003 at 06:37:55PM -0600, Tom Kaitchuck wrote:
Yes we do need to enforce it. Besides enforcing it is easy. Instead of
rejecting all incoming requests with a probability of %overload. Reject
them with probability of
On Wednesday 12 November 2003 11:31 am, Jim Dixon wrote:
On Wed, 12 Nov 2003, [iso-8859-1] Some Guy wrote:
Here's a neat paper Zooko (the MNet guy) pointed out:
http://citeseer.nj.nec.com/douceur02sybil.html They argue you'd need a
central authority to prevent a sybil attack. I think
On Wed, 2003-11-19 at 08:22, Thomas Themel wrote:
| Connections open (Inbound/Outbound/Limit) 299 (199/100/2048)
| Connections transferring (Transmitting/Receiving) 40 (12/28)
| Data waiting to be transfered 42 MiB
| Total amount of data
On Wed, 19 Nov 2003, Tom Kaitchuck wrote:
On Wednesday 12 November 2003 11:31 am, Jim Dixon wrote:
On Wed, 12 Nov 2003, [iso-8859-1] Some Guy wrote:
Here's a neat paper Zooko (the MNet guy) pointed out:
http://citeseer.nj.nec.com/douceur02sybil.html They argue you'd need a
central
My node is again receiving 30,000 QPH. But the sum of the number of
messages column on Open Connections page does not reflect this. In
fact, the sum does not keep increasing but fluctuates. I looked at
some of the incoming connection diagnostics, and concluded that I
am receiving a large number
Max data size is normally 1/100 of max ds size. If max ds size is
undefined max data size is also undefined, which was breaking
FSDataStore. As a fix I simply defined max data size as unlimited for
undefined values of max ds size.
Are you planning to do away with circular buffers when you
I have been investigating some problems... it seems that we still have a
problem with routing going mostly to new nodes (trying many new nodes
before finding one that works). I traced a new node added to the routing
table and it had really unrealistic estimators, despite them being from
the
Update of /cvsroot/freenet/freenet/src/freenet/node/rt
In directory sc8-pr-cvs1:/tmp/cvs-serv29317/src/freenet/node/rt
Modified Files:
StandardNodeEstimator.java
Log Message:
6342:
Disable QueryReject because of bandwidth.
Impose a maximum file size of 1MB plus storables.
Reset
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv29317/src/freenet/node/states/FNP
Modified Files:
NewRequest.java
Log Message:
6342:
Disable QueryReject because of bandwidth.
Impose a maximum file size of 1MB plus storables.
Reset
Update of /cvsroot/freenet/freenet/src/freenet/node/states/request
In directory sc8-pr-cvs1:/tmp/cvs-serv29317/src/freenet/node/states/request
Modified Files:
SendingReply.java
Log Message:
6342:
Disable QueryReject because of bandwidth.
Impose a maximum file size of 1MB plus storables.
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv29317/src/freenet
Modified Files:
Version.java
Log Message:
6342:
Disable QueryReject because of bandwidth.
Impose a maximum file size of 1MB plus storables.
Reset datasource when send file from store.
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FCP
In directory sc8-pr-cvs1:/tmp/cvs-serv29317/src/freenet/node/states/FCP
Modified Files:
NewClientPut.java NewClientGet.java
Log Message:
6342:
Disable QueryReject because of bandwidth.
Impose a maximum file size of 1MB plus
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv29317/src/freenet/node
Modified Files:
Node.java
Log Message:
6342:
Disable QueryReject because of bandwidth.
Impose a maximum file size of 1MB plus storables.
Reset datasource when send file from
Unstable build 6342 is in CVS. Major changes:
* Disable QueryRejecting because of bandwidth usage. See other mail,
forgot to commit 6341.
* Impose a maximum file size of 1MB plus storables.
Reason:
1. It makes multiplexing easier. We can eliminate CircularBuffer and
then we don't need to worry
Is there any reason not to keep the backoff data when a node is dropped
from the routing table?
--
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital
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.
___
Devl mailing list
[EMAIL PROTECTED]
On Saturday 15 November 2003 02:52 pm, Zlatin Balevsky wrote:
This idea may be rather unpopular, but too bad... :))
Rateless codes are like FEC except that they support infinite number of
checkblocks, and the file becomes a stream. Simple implementation is
just to wrap the
Martin Stone Davis wrote:
Ken Corson wrote:
Martin Stone Davis wrote:
Martin Stone Davis wrote:
We start at the top of the list, and see who is going to make our
will the fastest. Since our lawyer is backed off at the moment,
we go with our chef.
important: at the moment . How big do we
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 instance,
Freenet stable build 5039 is now available. Update your freenet node
using update.sh, freenet-webinstall.exe, or the jar (save it over
freenet.jar): http://freenetproject.org/snapshots/freenet-latest.jar .
Don't forget to restart the node (you will need to shut it down before
updating on Windows,
39 matches
Mail list logo
