Wow. In the last couple of hours, all of a sudden, all the active links
on the gateway page suddenly showed up (four of them, I removed TFEE).
All four loaded, other pages are loading.
I didn't update the node or anything, it just suddenly started working
really well.
-todd
_
Update of /cvsroot/freenet/freenet/src/freenet/fs/dir
In directory sc8-pr-cvs1:/tmp/cvs-serv13360
Modified Files:
FileNumber.java
Log Message:
Minor optimization and removal of unnecessary complexity
in calculation of the int hashCode: hashCode is calculated
once when object is created.
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv11693
Modified Files:
Message.java
Log Message:
fix typo in comment.
Index: Message.java
===
RCS file: /cvsroot/freenet/freenet/src/freene
Right now most nodes Query Reject a lot. Since a query reject is a waste
of both bandwidth and CPU, it would be nice to be able to avoid them
whenever possible. To that end, it should be possible to set a flag in a
QueryAccepted message indicating that the node is close to overload, but
has graciou
Me three.
-todd
On Sat, 11 Oct 2003, Pascal wrote:
> I have been having the same problem with this list. I wonder if it is
> not our email providers but the list itself?
>
> -Pascal
>
>
> Jonathan Howard wrote:
> >
> > I'm noticing not all messages are getting to my e-mail, I should change
I have been having the same problem with this list. I wonder if it is
not our email providers but the list itself?
-Pascal
Jonathan Howard wrote:
>
> I'm noticing not all messages are getting to my e-mail, I should change
> provider but I like free.
>
__
I'm noticing not all messages are getting to my e-mail, I should change
provider but I like free.
Niklas Bergh wrote:
Great!
But.. could you elaborate on the exact nature of the bug and what the
changes to WSL-select was?
RSL: removes selected key first time. Nothing major if it isn't, just
get
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv26203/src/freenet
Modified Files:
ConnectionHandler.java PeerHandler.java Version.java
Log Message:
minor simplifications in CH, keep opening conns if all ours are blocked with receiving
trailers, loggin
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv26203/src/freenet/node
Modified Files:
ConnectionOpener.java
Log Message:
minor simplifications in CH, keep opening conns if all ours are blocked with receiving
trailers, logging
Index: Connection
Running 6234 on two different nodes, one transient and one permanent node.
On the non-transient node I got this after 20 min.
Oct 11, 2003 2:16:45 PM (freenet.node.ConnectionOpener, QThread-1003,
NORMAL): No ref or not useful ref: DSA(1813 9a9c a246 9a5a 8359 b299
d081 0196 282c 9e61): session
On Sat, 2003-10-11 at 11:08, Todd Walton wrote:
> On Sat, 11 Oct 2003, Tim McGrath wrote:
>
> > Just a clarification, although the prodnet/fidnet is still using the 692
> > that was patched for the anonyminity bug (Thanks toad, you really helped
> > us out a lot.) I will be soon working on trying
On Sat, 11 Oct 2003 20:55:05 +0100, Toad <[EMAIL PROTECTED]> wrote:
it would be nice if you could warn people of a fproxy vulnerabilty, and
tell
them to upgrade (no fixed version yet)
example:
***end file.
Doesn't work. At least in unstable. Fixed months ago. Some idiot running
an ancient build.
Update of /cvsroot/freenet/freenet/src/freenet/fs/dir
In directory sc8-pr-cvs1:/tmp/cvs-serv29253/src/freenet/fs/dir
Modified Files:
NativeFSDirectory.java
Log Message:
6234:
* Limit the volume of queryrejects sent to a node due to version being too old.
Includes exponential backoff.
* D
Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv29253/src/freenet
Modified Files:
PeerHandler.java PeerPacket.java PeerPacketMessage.java
Version.java
Log Message:
6234:
* Limit the volume of queryrejects sent to a node due to version being to
Update of /cvsroot/freenet/freenet/src/freenet/diagnostics
In directory sc8-pr-cvs1:/tmp/cvs-serv29253/src/freenet/diagnostics
Modified Files:
FileEventList.java
Log Message:
6234:
* Limit the volume of queryrejects sent to a node due to version being too old.
Includes exponential backof
Update of /cvsroot/freenet/freenet/src/freenet/node
In directory sc8-pr-cvs1:/tmp/cvs-serv29253/src/freenet/node
Modified Files:
Main.java
Log Message:
6234:
* Limit the volume of queryrejects sent to a node due to version being too old.
Includes exponential backoff.
* Dump low priority
Update of /cvsroot/freenet/freenet/src/freenet/node/states/FNP
In directory sc8-pr-cvs1:/tmp/cvs-serv29253/src/freenet/node/states/FNP
Modified Files:
NewRequest.java
Log Message:
6234:
* Limit the volume of queryrejects sent to a node due to version being too old.
Includes exponential b
On Sat, Oct 11, 2003 at 08:55:05PM +0100, Toad wrote:
> On Sat, Oct 11, 2003 at 08:47:30PM +0100, Lee Stoneman wrote:
> > Hi Toad,
> > Here are the contents
> > ***begin file:
> > it would be nice if you could warn people of a fproxy vulnerabilty, and tell
> > them to upgrade (no fixed version yet)
On Sat, Oct 11, 2003 at 08:47:30PM +0100, Lee Stoneman wrote:
> Hi Toad,
> Here are the contents
> ***begin file:
> it would be nice if you could warn people of a fproxy vulnerabilty, and tell
> them to upgrade (no fixed version yet)
> example:
>
> ***end file.
Doesn't work. At least in unstable.
On 2003-10-11 at 21:04, Toad wrote:
> Practically, in terms of keeping a blacklist, we would probably simply
> remove the node from the routing table. MAYBE a limited list of nodes
> that permanently rejected us would be useful.
I think a limited list would be a good idea. And a warning to the us
On Thu, 2003-10-09 at 12:42, Frank O'Connor wrote:
> Have you tried inserting files? Have you tried pulling down files?
Sorry if I didn't test everything. I was writing to devl, not announce,
and I meant compared to 6221. My histogram of builds showed a lot
of people using builds far worse than
On Sat, Oct 11, 2003 at 08:56:28PM +0200, Benny Amorsen wrote:
> Right now there is no way to make a node stop sending queries. This
> would be useful e.g. when a node with a version lower than lastknowngood
> is querying. It would be very useful if a QueryReject could include a
> field saying "Don
Right now there is no way to make a node stop sending queries. This
would be useful e.g. when a node with a version lower than lastknowngood
is querying. It would be very useful if a QueryReject could include a
field saying "Don't query again". A well-behaved node would never send
queries to that n
On Fri, Oct 10, 2003 at 11:16:55PM +0200, Frank v Waveren wrote:
> On Fri, Oct 10, 2003 at 07:20:15PM +0100, Toad wrote:
> > There is also a trust question. Why should we trust the node that said
> > it had seen the message before?
> You can treat it the same as the node returning DNF (which nodes
> Please try 6229. And bear in mind that stable is not working at all by
> most accounts.
I am running 5028 and it is working about as well as usual. I can retrieve
stuff (old stuff, mostly) and the test inserts that I have done have worked. It
is having some problems with not keeping track of c
On Fri, Oct 10, 2003 at 07:20:15PM +0100, Toad wrote:
> There is also a trust question. Why should we trust the node that said
> it had seen the message before?
You can treat it the same as the node returning DNF (which nodes to which
you route can do anyway), there will still be more of a bias to
Hi there,
I have said this before, on my flog as well as on 3D17 as
on IIRC, etc.
Aside from the problems in coding, which I won't comment
on since I am not a coder, there is also a severe lack, in general, of proper
management.
'Proper' may have a different meaning in an Open Source
Have you tried inserting files? Have you tried pulling down files?
For 6226 I have about a hundred of these in my logs:
Oct 9, 2003 3:12:56 AM (freenet.node.states.data.SendData, QThread-292,
ERROR): Unexpected exception java.lang.NullPointerException in SendData
Sending Data @ 113959bc21b85dc7:
On Sat, Oct 11, 2003 at 06:09:05PM +0200, Niklas Bergh wrote:
> Great!
>
> But.. could you elaborate on the exact nature of the bug and what the
> changes to WSL-select was?
Looks like he removes most of our workaround code... just because the
API says it's unnecessary? Or why?
--
Matthew J Tos
On Sat, Oct 11, 2003 at 08:43:35AM -0700, Todd Walton wrote:
> On Sat, 11 Oct 2003, Ian Clarke wrote:
>
> > For the stable merge of the current unstable code, which will likely be
> > 5029, we should consider the benefits of increasing lastGoodBuild to
> > 5029. Some say that 5028 is next to us
Great!
But.. could you elaborate on the exact nature of the bug and what the
changes to WSL-select was?
/N
- Original Message -
From: "Jonathan Howard" <[EMAIL PROTECTED]>
To: "Discussion of development issues" <[EMAIL PROTECTED]>
Sent: Saturday, October 11, 2003 5:17 PM
Subject: [freenet
On Sat, Oct 11, 2003 at 04:34:27PM +0100, Ian Clarke wrote:
> For the stable merge of the current unstable code, which will likely be
> 5029, we should consider the benefits of increasing lastGoodBuild to
> 5029. Some say that 5028 is next to useless, however some of the best
> nodes in routing
Todd Walton wrote:
On Sat, 11 Oct 2003, Ian Clarke wrote:
For the stable merge of the current unstable code, which will likely be
5029, we should consider the benefits of increasing lastGoodBuild to
5029. Some say that 5028 is next to useless, however some of the best
nodes in routing tables
>If you set lastGoodBuild in 5029 to 5029, then new builds will have
>no one
>to talk to.
Incorrect. 5029 will still make requests to 5028 nodes, but it will prevent
5028 nodes from announcing into the network and effectively weed them
out over time. AFAIK.
>Better to set lastGoodBuild to 5028,
On Sat, 11 Oct 2003, Ian Clarke wrote:
> For the stable merge of the current unstable code, which will likely be
> 5029, we should consider the benefits of increasing lastGoodBuild to
> 5029. Some say that 5028 is next to useless, however some of the best
> nodes in routing tables I have seen
For the stable merge of the current unstable code, which will likely be
5029, we should consider the benefits of increasing lastGoodBuild to
5029. Some say that 5028 is next to useless, however some of the best
nodes in routing tables I have seen are 5028 nodes - so perhaps not.
Thoughts?
Ian
>If you're going to take responsibility for a fork, please also take
>>
>responsibility for ensuring the forked code doesn't bring down the
>>
>network as a whole.
He just wants to modify the code we're using as "stable" on Production
Freenet, which we do not endorse.
>
>Unless, of course, your
Attached is diff against 6233.
It fixes bug in RSL, adds WSL diagnostics and removes code that tries to
do the job of select.
diff -uwr freenet-unstable-latest/src/freenet/node/Main.java
Myfreenet-unstable-latest/src/freenet/node/Main.java
--- freenet-unstable-latest/src/freenet/node/Main.java
Todd Walton wrote:
On Sat, 11 Oct 2003, Ian Clarke wrote:
There is no reason
that Freenet nodes of differing abilities can't co-exist in the same
network provided that new additions aren't so destructive as to take
everyone else down.
Well, the point of the prodnet idea is that, as recently witn
On Sat, 11 Oct 2003, Tim McGrath wrote:
> Just a clarification, although the prodnet/fidnet is still using the 692
> that was patched for the anonyminity bug (Thanks toad, you really helped
> us out a lot.) I will be soon working on trying to fix some of the bugs
> I have seen in it without relyin
On Sat, 11 Oct 2003, Ian Clarke wrote:
> There is no reason
> that Freenet nodes of differing abilities can't co-exist in the same
> network provided that new additions aren't so destructive as to take
> everyone else down.
Well, the point of the prodnet idea is that, as recently witnessed, we
As unstable's performance improves the notion of separate networks looks
increasingly less attractive and sensible.
Lets not forget the cost of separate production and development
networks. These include a smaller Freenet network overall with
Freenet's most dedicated node operators split betwe
- Original Message -
From: "Niklas Bergh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 11, 2003 3:23 PM
Subject: [freenet-dev] There is something that still isn't fullt right
with6233
> The node is using up 90% of my CPU (probable reason is the large amount of
> thr
All,
Id just like to reinforce our goal with this experiment. We aim to provide
a coexisting parallel network consisting of the latest stable (and thoroughly
tested) official build(s).
I dont consider this to be a fork at this time a code fork is not
one of our goals.
A little quote from a f
The node is using up 90% of my CPU (probable reason is the large amount of
threads consumed as of below), I am seeing loads of these in the log
(probably due to the large amount of threads and CPU used too):
Long messageInitialStateTime 2656 : freenet.Message: DataRequest
@[EMAIL PROTECTED] for tc
On Fri, 2003-10-10 at 20:47, Pete wrote:
> This attitude is the sort of tabloid rubbish that landed the whole issue
> on /. The code that is being run on the network is pure freenet source,
> no hacks, no modifications other than to keep it from interfering with
> the main network, so they are runn
6226 and 6229 both feel better... Thanks for your work the past few
days.
For todays wild and crazy ideas we'll concentrate on fine tuning
requests... I'll order from most important to least important...
maxRequestsPerInterval=900
requestDelayCutoff=500
The second one is occasionally neces
One more quick note, if 6229 stats hold for a day (based upon the last
hour), when comparing it to what I had 3 days ago, query traffic (not
rejected) is up 8.2x, and the success rate went from 18.2% to 99.5%.
Everyone that is on >6190 and <6226, should update to 6229.
_
48 matches
Mail list logo
