[freenet-CVS] freenet/src/freenet/client ClientEventListener.java, 1.1.1.1, 1.2

[Edward J. Huff]

Update of /cvsroot/freenet/freenet/src/freenet/client
In directory sc8-pr-cvs1:/tmp/cvs-serv26422

Modified Files:
ClientEventListener.java 
Log Message:
Fix spelling errors in comments.


Index: ClientEventListener.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet/client/ClientEventListener.java,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- ClientEventListener.java13 Jan 2002 05:24:04 -  1.1.1.1
+++ ClientEventListener.java13 Oct 2003 04:40:54 -  1.2
@@ -1,7 +1,7 @@
 package freenet.client;
 
 /**
- * Event handeling for clients.
+ * Event handling for clients.
  *
  * @author oskar
  **/
@@ -10,7 +10,7 @@
 public interface ClientEventListener {
 
 /**
- * Hears and event.
+ * Hears an event.
  **/
 public void receive(ClientEvent ce);
 

___
cvs mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/cvs

Re: [freenet-dev] incoming at port -2 with build 6235

[Edward J. Huff]

On Sun, 2003-10-12 at 21:33, Zlatin Balevsky wrote:
> OCM lists some connections as incoming at port -2, -1...
> 
> -1208.39.42.23:35634  0   2,493 Bytes -   None0 s 1 s
> 35713 207.32.9.50:11975   366 299 KiB -   294 KiB 0 s
>  6:46
> -2207.32.9.50:11975   0   None-   None1:501:50

> and here's one that has had some data on it:
> -167.80.241.230:2366  4   541 Bytes   -   None0 s 10:36
> 

-1 means that ConnectionHandler.conn == null.
-2 means that conn.getSocket() threw an IOException.

conn is the tcpConnection member of the ConnectionHandler instance.
If conn turns out to be null during construction of the CH, you
get that "Already closed!" traceback.

Apparently this happens when the other end closes the TCP connection
very rapidly or else this end was slow in running the constructor.

So -1 must mean the other end has closed the TCP connection, and Fred
noticed the status on the read/write to the socket and set conn to
null, but OCM hasn't gotten a chance to tear down the freenet
connection.

Probably -2 means Fred hasn't noticed it at all yet, i.e. hasn't
selected the file descriptor of the socket and tried to read it,
but when it tried to do a getSocket, this gave an exception.

public int getLocalPort() {
tcpConnection c = conn;
java.net.Socket sock;
if (c == null) return -1;
try {
sock = conn.getSocket();
} catch (IOException e) { 
return -2;
}
if(sock == null) return -3;
return sock.getLocalPort();
}

-- Ed Huff



signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Performance Increase

[Salah Coronya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J wrote:

| Quoting "Edward J. Huff" <[EMAIL PROTECTED]>:
|
|
|>It would be interesting to see the node version histogram
|>of people who are getting good performance.
|
|
| I'm getting 'decent' performance.  Much better than late, but not the
best i've
| seen.
|
Then its not only me, I've notice a BIG performance increase as of build
6226. Pages and data are coming down much faster - before it would take
up to an hour to get the header of a splitfile (on average), now it
generally takes less than 5 minutes.  Even Freesites seem faster.
Furthermore, when it CAN'T find the data, the DNF's are coming faster
too. Inserts happen smoothly (I haven't tried to insert anything really
big - like an ISO - into Freenet yet. Previous versions would tend to
hang after many - say 100-200 blocks, but it would work in the next
insert attempt. I don't think anyone would notice unless you inserted
something over 10MB into Freenet)
I am running into a problem though - after leaving my node (6335)
running for 2 or 3 hours, I get lots of "Too many files open" exceptions
and my node is unusable until I restart it. Many (but not all) of the
previous unstable versions did this too, but not that quickly.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/ihn0hctESbvQ8ZwRAiCIAJ0ZfeEKPQArZ+cNn0tW0pVclW9U0wCfdaCH
/PmZOC7XgzRu7Cyzdbms8xI=
=AmcD
-END PGP SIGNATURE-
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] huge spike in MessageSendTime

[Zlatin Balevsky]

10/12/03 9:49:00 PM EDT	2704.2711934156378	21732.06106603715	1.0 
288242.0	2430
10/12/03 9:50:00 PM EDT	6820.178354978355	42211.21986746211	1.0 
649655.0	2310
10/12/03 9:51:00 PM EDT	4288.004818221638	24078.73450596664	1.0 
367618.0	2283
10/12/03 9:52:00 PM EDT	183713.43742735373	271629.6005761425	1.0 
780915.0	2581
10/12/03 9:53:00 PM EDT	100355.22946859903	135663.86406757613	1.0 
428186.0	2070
10/12/03 9:54:00 PM EDT	8250.383410138249	41549.13202139233	1.0 
408829.0	1085
10/12/03 9:55:00 PM EDT	287068.8330935252	369891.5728517046	1.0 
1006689.0	1390
10/12/03 9:56:00 PM EDT	200926.763956905	291210.63860275707	1.0 
1025903.0	1021
10/12/03 9:57:00 PM EDT	127102.50817610063	290334.1188493415	1.0 
1048756.0	795
10/12/03 9:58:00 PM EDT	2345.1584327086885	15985.076826654202	1.0 
146562.0	587
10/12/03 9:59:00 PM EDT	130786.80184331797	272572.86283760035	1.0 
947695.0	651
10/12/03 10:00:00 PM EDT	522376.01237964234	381900.17996493133	1.0	1014746.0
 this is almost 10 MINUTES!!! ^^^

I took a thread dump to see if anything can explain the spike. 
Interestingly, rsl was:

" read interface thread" daemon prio=1 tid=0x080edfb0 nid=0x5a98 
runnable [bddff000..bddff8d8]
at java.math.BigInteger.montReduce(BigInteger.java:1735)
at java.math.BigInteger.oddModPow(BigInteger.java:1692)
at java.math.BigInteger.modPow(BigInteger.java:1457)
at freenet.crypt.DSA.verify(DSA.java:77)
at freenet.DSAIdentity.verify(DSAIdentity.java:113)
at freenet.node.NodeReference.(NodeReference.java:218)
at freenet.node.NodeReference.(NodeReference.java:73)
at freenet.message.StoreData.(StoreData.java:44)
at 
sun.reflect.GeneratedConstructorAccessor18.newInstance(Unknown Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at freenet.MessageHandler.getMessageFor(MessageHandler.java:91)
at 
freenet.ConnectionHandler.innerProcess(ConnectionHandler.java:802)
at freenet.ConnectionHandler.process(ConnectionHandler.java:659)
at 
freenet.transport.ReadSelectorLoop.processConnections(ReadSelectorLoop.java:387)
at 
freenet.transport.AbstractSelectorLoop.loop(AbstractSelectorLoop.java:642)
at 
freenet.transport.ReadSelectorLoop.run(ReadSelectorLoop.java:436)
at java.lang.Thread.run(Thread.java:534)

while wsl was in BlockingQueue.dequeue().  The cpu was very low during 
these periods, the node receiving less than 4 kqph.

With messageSendTimes of almost 10 minutes, I don't see much point 
trying to run the unstable builds.  They certainly aren't helping the 
network any...

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] incoming at port -2 with build 6235

[Zlatin Balevsky]

sorry for the html, images were removed.

OCM lists some connections as incoming at port -2, -1...

-1

208.39.42.23:35634  0   2,493 Bytes -   None0 s 1 s
35713
207.32.9.50:11975   366 299 KiB -   294 KiB 0 s
 6:46
-2
	207.32.9.50:11975 	0 	None 	- 	None 	1:50 	1:50

and here's one that has had some data on it:
-1
	67.80.241.230:2366 	4 	541 Bytes 	- 	None 	0 s 	10:36



___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] QR/Overload behavior change

[Mathew Ryden]

Todd Walton wrote:
> On Sun, 12 Oct 2003, Benjamin Coates wrote:
>
> > A discussion on #freenet leads me to suggesting this change to
QueryReject
> > behavior:
> >
> > The goal here is to reduce the message traffic to overloaded nodes
without
> > seriously changing network behavior.
>
> What advantage does this have over the way it already happens, i.e.
> NGRouting.  With NGRouting, if a node is overloaded and QRs, everybody
> adjusts their appraisal of the node downwards, and message traffic to that
> overloaded node is reduced.
>
> What advantage does your above idea offer over the NGRouting effect?

Two things. One, it gives a method to know when a node is overloaded and
when it clears the condition. The second, is evidence from my own node that
it's not working. I'm running 6235. I have requesting nothing from freenet
other than the alinks on the frontpage.

inbound: 1645 nodes, 593481 attempts, 100151 accepted (16.88%), 852
successes (.85%)
outbound: 107 nodes, 986111 attempts

My node is accepting 16.9% of all queries, and then sending out 10 times as
many queries to find the data. I'm obviously causing quite a bit of traffic
on other nodes.

> (Not that there are no advantages, just asking what they are.)
>
> -todd

-Mathew

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] QR/Overload behavior change

[Todd Walton]

On Sun, 12 Oct 2003, Benjamin Coates wrote:

> A discussion on #freenet leads me to suggesting this change to QueryReject 
> behavior:
>
> The goal here is to reduce the message traffic to overloaded nodes without 
> seriously changing network behavior.

What advantage does this have over the way it already happens, i.e. 
NGRouting.  With NGRouting, if a node is overloaded and QRs, everybody 
adjusts their appraisal of the node downwards, and message traffic to that 
overloaded node is reduced.

What advantage does your above idea offer over the NGRouting effect?

(Not that there are no advantages, just asking what they are.)

-todd
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] various 6235 stack traces

[Niklas Bergh]

This one is fixed in CVS now.

regards
/N

> x3 (twice one after another followed by the next set of exceptions 16
times
> by 8 threads)
> Oct 11, 2003 10:57:11 PM (freenet.OpenConnectionManager$ConnectionJob,
> QThread-29604, ERROR): Unhandled throwable while handling connection
>
([EMAIL PROTECTED],freenet.ConnectionHandler
> @138626c for tcp/connection:
>
CLOSED,[EMAIL PROTECTED],[EMAIL PROTECTED]
> , sending null:-1)
> java.lang.NullPointerException
>  at freenet.support.MultiValueTable.countAll(MultiValueTable.java:72)
>  at
>
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:455)
>  at
>
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:451)
>  at
>
freenet.OpenConnectionManager.KillSurplusConnections(OpenConnectionManager.j
> ava:658)
>  at freenet.OpenConnectionManager.put(OpenConnectionManager.java:234)
>  at freenet.ConnectionHandler.registerOCM(ConnectionHandler.java:383)
>  at
>
freenet.OpenConnectionManager$ConnectionJob.run(OpenConnectionManager.java:1
> 573)
>  at
>
freenet.OpenConnectionManager.createConnection(OpenConnectionManager.java:52
> 4)
>  at freenet.node.ConnectionOpener.checkpoint(ConnectionOpener.java:169)
>  at
> freenet.node.states.maintenance.Checkpoint.checkpoint(Checkpoint.java:56)
>  at
freenet.node.states.maintenance.Checkpoint.received(Checkpoint.java:49)
>  at freenet.node.StateChain.received(StateChain.java:190)
>  at freenet.node.StateChain.received(StateChain.java:71)
>  at
>
freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2
> 26)
>  at
>
freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j
> ava:165)
>  at
>
freenet.node.StandardMessageHandler$Ticket.access$100(StandardMessageHandler
> .java:123)
>  at
> freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:71)
>  at freenet.Ticker$Event.run(Ticker.java:284)
>  at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:221)
> Oct 11, 2003 10:57:11 PM (freenet.node.states.maintenance.Checkpoint,
> QThread-29604, ERROR): unhandled throwable in Checkpoint: Connection
opener
> @ DSA(ddc8 f6ca 7e1f 9651 90d0  7faa 726e e527 88a0 0df4):
> java.lang.NullPointerException
> java.lang.NullPointerException
>  at freenet.support.MultiValueTable.countAll(MultiValueTable.java:72)
>  at
>
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:455)
>  at
>
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:451)
>  at
>
freenet.OpenConnectionManager.KillSurplusConnections(OpenConnectionManager.j
> ava:658)
>  at freenet.OpenConnectionManager.put(OpenConnectionManager.java:234)
>  at freenet.ConnectionHandler.registerOCM(ConnectionHandler.java:383)
>  at
>
freenet.OpenConnectionManager$ConnectionJob.run(OpenConnectionManager.java:1
> 573)
>  at
>
freenet.OpenConnectionManager.createConnection(OpenConnectionManager.java:52
> 4)
>  at freenet.node.ConnectionOpener.checkpoint(ConnectionOpener.java:169)
>  at
> freenet.node.states.maintenance.Checkpoint.checkpoint(Checkpoint.java:56)
>  at
freenet.node.states.maintenance.Checkpoint.received(Checkpoint.java:49)
>  at freenet.node.StateChain.received(StateChain.java:190)
>  at freenet.node.StateChain.received(StateChain.java:71)
>  at
>
freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2
> 26)
>  at
>
freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j
> ava:165)
>  at
>
freenet.node.StandardMessageHandler$Ticket.access$100(StandardMessageHandler
> .java:123)
>  at
> freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:71)
>  at freenet.Ticker$Event.run(Ticker.java:284)
>  at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:221)
>
> Oct 12, 2003 6:27:37 AM (freenet.interfaces.PublicNIOInterface,
> QThread-116598, ERROR): Unhandled throwable while handling connection
> java.lang.NullPointerException
>  at freenet.support.MultiValueTable.countAll(MultiValueTable.java:72)
>  at
>
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:455)
>  at
>
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:451)
>  at
>
freenet.OpenConnectionManager.KillSurplusConnections(OpenConnectionManager.j
> ava:658)
>  at freenet.OpenConnectionManager.put(OpenConnectionManager.java:234)
>  at freenet.ConnectionHandler.registerOCM(ConnectionHandler.java:383)
>  at
>
freenet.interfaces.FreenetConnectionRunner.handle(FreenetConnectionRunner.ja
> va:135)
>  at
>
freenet.interfaces.PublicNIOInterface$ConnectionShell.run(PublicNIOInterface
> .java:147)
>  at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:221)
> 
>
> I received the same Unhanled throwable while handling connection NPE in
> freenet.support.MultiValueTable.countAll another 42 times, always in
two's.
>

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/dev

[freenet-dev] Problem with 6235 (and possibly 6234)

[Niklas Bergh]

Latest unstable (or possible latest two unstable or so) build tries to open
too many connections using the ConnectionOpener.
My node uses 100% CPU and the profiler indicates that it is caused by the
ConnectionOpener. The outboundOpenerConnections
 diagnostics indicates that there is somewhere between 7k and 13k
connections opened per hour... An effect of this is that routingTime is way
up and that the node therefore QR:s..

/N

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-CVS] freenet/src/freenet/support MultiValueTable.java, 1.3, 1.4

[Niklas Bergh]

Update of /cvsroot/freenet/freenet/src/freenet/support
In directory sc8-pr-cvs1:/tmp/cvs-serv14700/src/freenet/support

Modified Files:
MultiValueTable.java 
Log Message:
If we dont have any entries for the object then return 0 instead of NPE:ing

Index: MultiValueTable.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet/support/MultiValueTable.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MultiValueTable.java26 Sep 2003 22:38:35 -  1.3
+++ MultiValueTable.java12 Oct 2003 22:55:34 -  1.4
@@ -69,7 +69,11 @@
 }
 
 public int countAll(Object key) {
-return ((Vector)table.get(key)).size();
+   Vector v = (Vector)table.get(key);
+   if(v != null) 
+   return v.size();
+else
+   return 0;
 }
 
 public Object getSync(Object key) {

___
cvs mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/cvs

Re: [freenet-dev] Couple suggestions

[Frank v Waveren]

On Fri, Oct 10, 2003 at 11:13:13PM +0100, Toad wrote:
> > 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 routing
> > that area of the keyspace to the node that actually specialises in it than
> > to other nodes.
> Okay, so they'd be "punished" in the estimators - the probability of DNF
> for a given key would be updated on the graph?
Yes. I can't imagine this being a big deal, as a same request in the current
system with a HTL that would make it end without looping would punish that
node too.


-- 
Frank v Waveren  Fingerprint: 21A7 C7F3
[EMAIL PROTECTED]|stack.nl|dse.nl] ICQ#10074100   1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[EMAIL PROTECTED]7BD9 09C0 3AC1 6DF2
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] various 6235 stack traces

[Mathew Ryden]

I've been running 6235 here for about 20 hours, and I've received a plethora
of different stacktraces.

This one I received twice hours apart:
Oct 11, 2003 8:47:18 PM (freenet.node.states.request.DataPending,
QThread-6180, ERROR): I/O error storing DataReply:
freenet.node.ds.StoreIOException: freenet.node.ds.KeyCollisionException
(freenet.node.states.request.DataPending:
key=6b8f751ae236aebbd67c38076bbba7808137e9380f0203, hopsToLive=19,
id=c54cbf0b2bc0346d, [EMAIL PROTECTED]
(6b8f751ae236aebbd67c38076bbba7808137e9380f0203,request),ft=freenet.node.sta
[EMAIL PROTECTED]@1065919638580, routedTime=1065919626307,
replyTime=-1, outwardSender=null)
freenet.node.ds.StoreIOException: freenet.node.ds.KeyCollisionException
 at freenet.message.DataSend.cacheData(DataSend.java:142)
 at freenet.node.states.request.Pending.receivedDataReply(Pending.java:396)
 at
freenet.node.states.request.DataPending.receivedMessage(DataPending.java:108
)
 at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at freenet.node.State.received(State.java:126)
 at freenet.node.StateChain.received(StateChain.java:190)
 at freenet.node.StateChain.received(StateChain.java:71)
 at
freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2
26)
 at
freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j
ava:165)
 at
freenet.node.StandardMessageHandler$Ticket.access$100(StandardMessageHandler
.java:123)
 at
freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:71)
 at freenet.Ticker$Event.run(Ticker.java:284)
 at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:221)
Caused by: freenet.node.ds.KeyCollisionException
 at freenet.node.ds.FSDataStore.putData(FSDataStore.java:118)
 at freenet.message.DataSend.cacheData(DataSend.java:140)
 ... 14 more



This was received 6 times, sometimes together, sometimes alone
Oct 11, 2003 9:23:28 PM (freenet.transport.WriteSelectorLoop,  write
interface thread, ERROR): Caught java.lang.NullPointerException notifying
[EMAIL PROTECTED] for null,null, sending null:-1 for
java.nio.channels.SocketChannel[closed] in processConnections
java.lang.NullPointerException
 at freenet.ConnectionHandler.jobDone(ConnectionHandler.java:1206)
 at
freenet.transport.WriteSelectorLoop.processConnections(WriteSelectorLoop.jav
a:680)
 at
freenet.transport.AbstractSelectorLoop.loop(AbstractSelectorLoop.java:642)
 at freenet.transport.WriteSelectorLoop.run(WriteSelectorLoop.java:736)
 at java.lang.Thread.run(Thread.java:534)




x3 (twice one after another followed by the next set of exceptions 16 times
by 8 threads)
Oct 11, 2003 10:57:11 PM (freenet.OpenConnectionManager$ConnectionJob,
QThread-29604, ERROR): Unhandled throwable while handling connection
([EMAIL PROTECTED],freenet.ConnectionHandler
@138626c for tcp/connection:
CLOSED,[EMAIL PROTECTED],[EMAIL PROTECTED]
, sending null:-1)
java.lang.NullPointerException
 at freenet.support.MultiValueTable.countAll(MultiValueTable.java:72)
 at
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:455)
 at
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:451)
 at
freenet.OpenConnectionManager.KillSurplusConnections(OpenConnectionManager.j
ava:658)
 at freenet.OpenConnectionManager.put(OpenConnectionManager.java:234)
 at freenet.ConnectionHandler.registerOCM(ConnectionHandler.java:383)
 at
freenet.OpenConnectionManager$ConnectionJob.run(OpenConnectionManager.java:1
573)
 at
freenet.OpenConnectionManager.createConnection(OpenConnectionManager.java:52
4)
 at freenet.node.ConnectionOpener.checkpoint(ConnectionOpener.java:169)
 at
freenet.node.states.maintenance.Checkpoint.checkpoint(Checkpoint.java:56)
 at freenet.node.states.maintenance.Checkpoint.received(Checkpoint.java:49)
 at freenet.node.StateChain.received(StateChain.java:190)
 at freenet.node.StateChain.received(StateChain.java:71)
 at
freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2
26)
 at
freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j
ava:165)
 at
freenet.node.StandardMessageHandler$Ticket.access$100(StandardMessageHandler
.java:123)
 at
freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:71)
 at freenet.Ticker$Event.run(Ticker.java:284)
 at freenet.thread.QThreadFactory$QThread.run(QThreadFactory.java:221)
Oct 11, 2003 10:57:11 PM (freenet.node.states.maintenance.Checkpoint,
QThread-29604, ERROR): unhandled throwable in Checkpoint: Connection opener
@ DSA(ddc8 f6ca 7e1f 9651 90d0  7faa 726e e527 88a0 0df4):
java.lang.NullPointerException
java.lang.NullPointerException
 at freenet.support.MultiValueTable.countAll(MultiValueTable.java:72)
 at
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnectionManager.java:455)
 at
freenet.OpenConnectionManager.onlyRTNodeConn(OpenConnecti

RE: [freenet-dev] QR/Overload behavior change

[Benjamin Coates]

> From Chris Carlin <[EMAIL PROTECTED]>

>This way the overloaded node doesn't have to keep track of who it's told
>to go away and then offer services to nodes that might no longer wish to
>issue requests. Since you've suggested a timeout of an hour it seems as
>if there's time for this and other similar problems to occur.

The hour timeout is only there for dealing with a malfunctioning node (for 
example, being restarted and losing the list of QRs) to limit how long a node 
will wait, it's not supposed to mean "Come back in an hour".

Considering how many unneeded QueryReject messages this could potentially 
replace, It's not a great tragedy for some unneeded go-ahead messages to be 
generated.

--
Benjamin Coates

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

RE: [freenet-dev] Performance Increase

[Todd Walton]

On Sun, 12 Oct 2003, Edward J. Huff wrote:

> It would be interesting to see the node version histogram
> of people who are getting good performance. 

I'm getting pretty good performance.

Oct 12, 2003 1:40:10 PM
nodes: 49
scale factor: 1.0 (This is used to keep lines < 64 characters)

Fred,0.5,1.46,5013 |=
Fred,0.5,1.46,5018 |=
Fred,0.5,1.46,5023 |=
Fred,0.5,1.46,5028 |=
Fred,0.6,1.46,6183 |=
Fred,0.6,1.46,6194 |=
Fred,0.6,1.46,6207 |=
Fred,0.6,1.46,6214 |=
Fred,0.6,1.46,6215 |===
Fred,0.6,1.46,6226 |===
Fred,0.6,1.46,6233 |==
Fred,0.6,1.46,6234 |=
Fred,0.6,1.46,6235 |===
Fred,0.6,1.46,7050 |=

mean: 3.5

peaks (count/mean)
Fred,0.5,1.46,5028 --> (8.285714)
Fred,0.6,1.46,6235 --> (0.85714287)

-todd
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

RE: [freenet-dev] Performance Increase

[J]

Quoting "Edward J. Huff" <[EMAIL PROTECTED]>:

> It would be interesting to see the node version histogram
> of people who are getting good performance. 

I'm getting 'decent' performance.  Much better than late, but not the best i've
seen.

Histogram of node versions in fred's Routing table

Oct 12, 2003 3:18:33 PM
nodes: 50
scale factor: 1.0 (This is used to keep lines < 64 characters)

Fred,0.5,1.46,5023 |=
Fred,0.5,1.46,5024 |=
Fred,0.5,1.46,5028 |
Fred,0.5,1.46,572  |=
Fred,0.6,1.46,6168 |=
Fred,0.6,1.46,6193 |=
Fred,0.6,1.46,6194 |=
Fred,0.6,1.46,6206 |=
Fred,0.6,1.46,6215 |
Fred,0.6,1.46,6223 |=
Fred,0.6,1.46,6226 |===
Fred,0.6,1.46,6233 |
Fred,0.6,1.46,6234 |=
Fred,0.6,1.46,6235 |=
Fred,0.6,1.46,7050 |=

mean: 3.333

peaks (count/mean)
Fred,0.5,1.46,5028 --> (8.41)
Fred,0.6,1.46,6215 --> (1.2)
Fred,0.6,1.46,6233 --> (1.2)

j.

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] QR/Overload behavior change

[Mathew Ryden]

Chris Carlin wrote:

> Benjamin Coates wrote:
> > 4. This state persists until B sends A a "go-ahead" message, or a
timeout (1
> > hour?) expires, in case B malfunctions and forgot who it owes a message.
>
> I instinctively question the "go ahead" part of this idea.
>
> Perhaps it would be preferable to instead include a suggested timeout
> (based on whatever) in the "leave me alone" message?

How do we know how long the node will be overloaded? Should we just guess a
number, or should we somehow try to prove a way of guessing the time the
node will be overloaded (alchemy)?

The purpose of this scheme is to prevent such alchemy from being written.
There is no magic. When the node is grossly overloaded, it QRs everything in
such a way as to stop the nodes from trying to contact them again. When the
overload condition is removed, it tells the nodes that it is available
again.

> This way the overloaded node doesn't have to keep track of who it's told
> to go away and then offer services to nodes that might no longer wish to
> issue requests. Since you've suggested a timeout of an hour it seems as
> if there's time for this and other similar problems to occur.
>
> ~Chris

-Mathew

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] QR/Overload behavior change

[Chris Carlin]

Benjamin Coates wrote:
4. This state persists until B sends A a "go-ahead" message, or a timeout (1 
hour?) expires, in case B malfunctions and forgot who it owes a message.
I instinctively question the "go ahead" part of this idea.

Perhaps it would be preferable to instead include a suggested timeout 
(based on whatever) in the "leave me alone" message?

This way the overloaded node doesn't have to keep track of who it's told 
to go away and then offer services to nodes that might no longer wish to 
issue requests. Since you've suggested a timeout of an hour it seems as 
if there's time for this and other similar problems to occur.

~Chris

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] QR/Overload behavior change

[Benjamin Coates]

A discussion on #freenet leads me to suggesting this change to QueryReject 
behavior:

1. A sends B a request
2. B is overloaded, sends A a QueryReject, with an additional field indicating 
to wait until told otherwise.
3. A now assumes that B is overloaded, and any further requests to it will 
QueryReject, so it behaves as if they have without actually sending the 
message.
4. This state persists until B sends A a "go-ahead" message, or a timeout (1 
hour?) expires, in case B malfunctions and forgot who it owes a message.

The goal here is to reduce the message traffic to overloaded nodes without 
seriously changing network behavior.

The node needs a method for deciding when to send QRs and when to send 
go-aheads.  The node might keep a queue of nodes which have been sent QRs, and 
a list of nodes which have been sent goaheads, where it would pop a node off 
the QR list and send a goahead when it is not overloaded (at some reasonable 
rate), and send QRs to all requests from nodes in neither list, until the QR 
list is empty; then when the node becomes overloaded again, it would empty the 
goahead list, which would cause all requests to be QRed again.

Comments?

--
Benjamin Coates

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

RE: [freenet-dev] Performance Increase

[Edward J. Huff]

On Sun, 2003-10-12 at 12:57, Simon Porter wrote:
> I'd second the report of better performance. Pages are now loading in
> seconds instead of minutes! These aren't pages I have already cached on my
> node either. I guess NGrouting really is really paying off.
> 
> One thing I would like to see put back on the node status page is a link to
> the routing page. It was removed at some point for a reason unknown to me.
> 
> Simon

I'm not seeing spectacular performance right now with 6235.
The front page of YoYo loaded right away.  So I started
loading all of the second level pages.  Only one or two
came up.  The rest are getting route not found.

It would be interesting to see the node version histogram
of people who are getting good performance. 

-- Ed Huff

http://127.0.0.1:/servlet/nodestatus/version_histogram.txt

Histogram of node versions in fred's Routing table

Oct 12, 2003 2:04:12 PM
nodes: 50
scale factor: 1.0 (This is used to keep lines < 64 characters)

Fred,0.5,1.46,5028 |===
Fred,0.6,1.46,6168 |=
Fred,0.6,1.46,6205 |=
Fred,0.6,1.46,6213 |=
Fred,0.6,1.46,6214 |===
Fred,0.6,1.46,6215 |==
Fred,0.6,1.46,6223 |==
Fred,0.6,1.46,6226 |
Fred,0.6,1.46,6229 |==
Fred,0.6,1.46,6233 |=
Fred,0.6,1.46,6235 |==

mean: 4.5454545

peaks (count/mean)
Fred,0.5,1.46,5028 --> (5.06)
Fred,0.6,1.46,6215 --> (1.32)
Fred,0.6,1.46,6226 --> (0.88)
Fred,0.6,1.46,6233 --> (1.1)



signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: Smoketests (Was: Re: [freenet-dev] Re: It Has Begun

[Edward J. Huff]

On Sun, 2003-10-12 at 13:01, Reskill wrote:

> I believe that without a clear definition between testing and stable
> networks, recent occurrences regarding network degradation are bound
> to happen again, sooner rather than later. Much better, then, to push
> to a stable "clean slate" with the next well-tested stable build, and
> always maintain this migration step with each significant new stable
> release.
> 
> It is definitely time that new procedures were put into place to safeguard
> network performance and the freenet userbase, especially if any truly
> worthwhile content is to surface in our network.
> 

I agree that better procedures are necessary.  However, you should
note that right now, all anyone who wants to knock freenet down
needs to do is get about 50 nodes well integrated and then switch
them to 6025 or so, using a version that claims to be something
else.

Having our developers and beta testers refrain from connecting
to the live network is not going to remove the vulnerability
which has just been exposed.  Rather, we have to fix fred so
that it blacklists nodes which are behaving badly.  

We will, I'm sure, refrain from testing this fix on the live 
network, since right now, the test would knock down all nodes 
not running the fixed version.

Also, I'm working on a version of Version.java which supports
more flexible ways of excluding nodes which are polite enough
to specify their true build number but which are not working.

-- Ed Huff



signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: Smoketests (Was: Re: [freenet-dev] Re: It Has Begun

[Reskill]

Hi,

I believe this email to be extremely accurate and well written. It echos
many of the calls we have been making over the last few days regarding
a production network, and I would particularly like to draw attention
to:
>2) Users migrate to a new, separate production network. Current
>Freenet
>becomes test network.
>- - pro: rapid performance improvement for user base. Clean start
>for
>production network. Minimal effort for developers.
>- - con: users need to actively migrate. Test network is cluttered
>with
>versions. Psychological effort of "giving up" current Freenet and
>"giving in" to dissident users.

I believe that without a clear definition between testing and stable
networks, recent occurrences regarding network degradation are bound
to happen again, sooner rather than later. Much better, then, to push
to a stable "clean slate" with the next well-tested stable build, and
always maintain this migration step with each significant new stable
release.

It is definitely time that new procedures were put into place to safeguard
network performance and the freenet userbase, especially if any truly
worthwhile content is to surface in our network.

--Reskill

On Sun, 12 Oct 2003 08:22:07 -0700 Menno Jonkers <[EMAIL PROTECTED]>
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Ian,
>
>Ian Clarke wrote:
>| As unstable's performance improves the notion of separate networks
>| looks increasingly less attractive and sensible.
>
>| [...] 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.
>
>| [...] This can form the basis of a test network
>
>I'm not sure whether you're suggesting to set-up a separate test
>network
>or have these tests run against production. Anyway, I'll spew my
>2 cents
>below and would be interested to have your vision on that.
>
>
>I'd expect that as the user base and application (i.e. non-research
>use)
>of Freenet grow, the stability requirements of this network & community
>will leave less and less room for test activities. Consequently
>updates
>of software should be introduced in a very cautious and controlled
>way.
>With the highly interconnected nature of Freenet this implies a
>very
>high level of quality assurance.
>
>This requires a fundamental change from the current practice in
>which
>debugging is largely performed in the production network, with an
>uncontrolled number of "development nodes" with different versions
>of
>software at different levels of maturity. The result is a network
>that's
>basically unmanageable, as underlined by the recent inability to
>both
>quickly identify and resolve a significant loss of performance.
>A new,
>well performing unstable may reduce this pain but will at best postpone
>the need for a change.
>
>Requirements for a production network:
>1) Nodes run only software versions proved stable
>2) The number of different versions in the network is minimal
>3) Updates (minor changes) are limited to security & anonymity fixes
>4) Upgrades (major changes) are rare (say bi-annual) and done to
>only to
>software versions proved stable
>
>Note that 3) implies a production fork. Pretty usual.
>
>But how to prove proper behavior of a new version if you cannot
>do real
>life tests? You probably can't. At some point in time the new software
>needs to be exposed to the production network and vice versa.
>
>A scenario to do this with a minimal risk of impact on the production
>network would be:
>1) Development and extensive testing are done on a separate test
>network; smoke tests are part of this
>2) Once a version is reached that has shown to work well on the
>test
>network, a feature freeze can happen and this can become a Release
>Candidate 1
>3) A limited number of RC1 nodes is introduced (or upgraded from
>production versions) in the production network for a limited amount
>of
>time. Their behavior is observed and analyzed, resulting in bug
>reports.
>4) The RC1 nodes are removed from the production network (or downgraded
>to production versions).
>5) It is explicitly decided which bugs are going to be fixed to
>go from
>RC1 to RC2. No other bug fixes or features are introduced: code
>freeze.
>6) RC2 is tested, i.e. goto 3)
>7) Once an RC is reached that seems acceptable for production use,
> one
>could do a large scale test of it on the production network. And
>if it
>runs fine on a large number of nodes for say a month, it could become
>the official new release.
>
>This is a fairly basic software development process (and as always
>there
>will be some discussion on the line between feature and bug fix).
>
>The key things here are:
>a) Developers still have a lot of freedom at stage 1)
>b) Testing is highly controlled, both in scope and time
>c) Whichever person/entity decides what requires fixing at 5) should
>/primarily/ represent the interests of the production network.
>
>Clearly both b) and c) imply changes 

RE: [freenet-dev] Performance Increase

[Simon Porter]

I'd second the report of better performance. Pages are now loading in
seconds instead of minutes! These aren't pages I have already cached on my
node either. I guess NGrouting really is really paying off.

One thing I would like to see put back on the node status page is a link to
the routing page. It was removed at some point for a reason unknown to me.

Simon

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:devl-
> [EMAIL PROTECTED] On Behalf Of Edgar Friendly
> Sent: 12 October 2003 14:24
> To: Discussion of development issues
> Subject: Re: [freenet-dev] Performance Increase
> 
> Todd Walton <[EMAIL PROTECTED]> writes:
> 
> > 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
> 
> That's one of the frustrating things about debugging freenet.  There's
> not necessarily any correlation between your node's stability/its
> bugginess and its performance.  Thanks for letting people know there's
> hope.
> 
> Thelema
> --
> E-mail: [EMAIL PROTECTED]Raabu and Piisu
> GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7  84B7 D8D7 6ECE 3635 2AAB
> ___
> Devl mailing list
> [EMAIL PROTECTED]
> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl



___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

RE: Smoketests (Was: Re: [freenet-dev] Re: It Has Begun

[Pete]

I'm up for either option, as long as the users get a stable network to
use, I've been testing 6233 most of this afternoon, inserts are flying,
92 megs in just over an hour! Wikked! FIW still has issues with my site
but that'll get resolved I'm sure. I think once node integration is
sorted (I 've still had no inbound insert / request search keys let
alone successful attempts though my node is accepting all connection
attemps successfully :-/ )

I'd say if these issues can be resolved I'll back this build as stable,
and move my now 4 gig store back to the main network as long as
develoment nodes are worked on in a separate network, as suggested
below.

Pete

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Menno Jonkers
Sent: 12 October 2003 16:22
To: Discussion of development issues
Subject: Re: Smoketests (Was: Re: [freenet-dev] Re: It Has Begun 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ian,

Ian Clarke wrote:
| As unstable's performance improves the notion of separate networks 
| looks increasingly less attractive and sensible.

| [...] 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.

| [...] This can form the basis of a test network

I'm not sure whether you're suggesting to set-up a separate test network
or have these tests run against production. Anyway, I'll spew my 2 cents
below and would be interested to have your vision on that.


I'd expect that as the user base and application (i.e. non-research use)
of Freenet grow, the stability requirements of this network & community
will leave less and less room for test activities. Consequently updates
of software should be introduced in a very cautious and controlled way.
With the highly interconnected nature of Freenet this implies a very
high level of quality assurance.

This requires a fundamental change from the current practice in which
debugging is largely performed in the production network, with an
uncontrolled number of "development nodes" with different versions of
software at different levels of maturity. The result is a network that's
basically unmanageable, as underlined by the recent inability to both
quickly identify and resolve a significant loss of performance. A new,
well performing unstable may reduce this pain but will at best postpone
the need for a change.

Requirements for a production network:
1) Nodes run only software versions proved stable
2) The number of different versions in the network is minimal
3) Updates (minor changes) are limited to security & anonymity fixes
4) Upgrades (major changes) are rare (say bi-annual) and done to only to
software versions proved stable

Note that 3) implies a production fork. Pretty usual.

But how to prove proper behavior of a new version if you cannot do real
life tests? You probably can't. At some point in time the new software
needs to be exposed to the production network and vice versa.

A scenario to do this with a minimal risk of impact on the production
network would be:
1) Development and extensive testing are done on a separate test
network; smoke tests are part of this
2) Once a version is reached that has shown to work well on the test
network, a feature freeze can happen and this can become a Release
Candidate 1
3) A limited number of RC1 nodes is introduced (or upgraded from
production versions) in the production network for a limited amount of
time. Their behavior is observed and analyzed, resulting in bug reports.
4) The RC1 nodes are removed from the production network (or downgraded
to production versions).
5) It is explicitly decided which bugs are going to be fixed to go from
RC1 to RC2. No other bug fixes or features are introduced: code freeze.
6) RC2 is tested, i.e. goto 3)
7) Once an RC is reached that seems acceptable for production use, one
could do a large scale test of it on the production network. And if it
runs fine on a large number of nodes for say a month, it could become
the official new release.

This is a fairly basic software development process (and as always there
will be some discussion on the line between feature and bug fix).

The key things here are:
a) Developers still have a lot of freedom at stage 1)
b) Testing is highly controlled, both in scope and time
c) Whichever person/entity decides what requires fixing at 5) should
/primarily/ represent the interests of the production network.

Clearly both b) and c) imply changes to the current process. They should
remove much of it's current alchemy.


Finally there's the touchy issue of separating networks. There are two
basic routes here, with pros and cons:

1) Developers move their activities to a separate test network. Current
Freenet becomes (stays) production network.
- - pro: no impact on the current user base, no need to migrate
- - con: no rapid performance improvement for current user base. Unclear
how to evolve th

Re: Smoketests (Was: Re: [freenet-dev] Re: It Has Begun

[Menno Jonkers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian,

Ian Clarke wrote:
| As unstable's performance improves the notion of separate networks
| looks increasingly less attractive and sensible.
| [...] 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.
| [...] This can form the basis of a test network

I'm not sure whether you're suggesting to set-up a separate test network
or have these tests run against production. Anyway, I'll spew my 2 cents
below and would be interested to have your vision on that.
I'd expect that as the user base and application (i.e. non-research use)
of Freenet grow, the stability requirements of this network & community
will leave less and less room for test activities. Consequently updates
of software should be introduced in a very cautious and controlled way.
With the highly interconnected nature of Freenet this implies a very
high level of quality assurance.
This requires a fundamental change from the current practice in which
debugging is largely performed in the production network, with an
uncontrolled number of "development nodes" with different versions of
software at different levels of maturity. The result is a network that's
basically unmanageable, as underlined by the recent inability to both
quickly identify and resolve a significant loss of performance. A new,
well performing unstable may reduce this pain but will at best postpone
the need for a change.
Requirements for a production network:
1) Nodes run only software versions proved stable
2) The number of different versions in the network is minimal
3) Updates (minor changes) are limited to security & anonymity fixes
4) Upgrades (major changes) are rare (say bi-annual) and done to only to
software versions proved stable
Note that 3) implies a production fork. Pretty usual.

But how to prove proper behavior of a new version if you cannot do real
life tests? You probably can't. At some point in time the new software
needs to be exposed to the production network and vice versa.
A scenario to do this with a minimal risk of impact on the production
network would be:
1) Development and extensive testing are done on a separate test
network; smoke tests are part of this
2) Once a version is reached that has shown to work well on the test
network, a feature freeze can happen and this can become a Release
Candidate 1
3) A limited number of RC1 nodes is introduced (or upgraded from
production versions) in the production network for a limited amount of
time. Their behavior is observed and analyzed, resulting in bug reports.
4) The RC1 nodes are removed from the production network (or downgraded
to production versions).
5) It is explicitly decided which bugs are going to be fixed to go from
RC1 to RC2. No other bug fixes or features are introduced: code freeze.
6) RC2 is tested, i.e. goto 3)
7) Once an RC is reached that seems acceptable for production use, one
could do a large scale test of it on the production network. And if it
runs fine on a large number of nodes for say a month, it could become
the official new release.
This is a fairly basic software development process (and as always there
will be some discussion on the line between feature and bug fix).
The key things here are:
a) Developers still have a lot of freedom at stage 1)
b) Testing is highly controlled, both in scope and time
c) Whichever person/entity decides what requires fixing at 5) should
/primarily/ represent the interests of the production network.
Clearly both b) and c) imply changes to the current process. They should
remove much of it's current alchemy.
Finally there's the touchy issue of separating networks. There are two
basic routes here, with pros and cons:
1) Developers move their activities to a separate test network. Current
Freenet becomes (stays) production network.
- - pro: no impact on the current user base, no need to migrate
- - con: no rapid performance improvement for current user base. Unclear
how to evolve this into clean, few version production network. Requires
developer effort. Test network will be small at first.
2) Users migrate to a new, separate production network. Current Freenet
becomes test network.
- - pro: rapid performance improvement for user base. Clean start for
production network. Minimal effort for developers.
- - con: users need to actively migrate. Test network is cluttered with
versions. Psychological effort of "giving up" current Freenet and
"giving in" to dissident users.
(Work out option 3, two new networks, and option 4, nothing changes
really, yourself.)
Currently I tend to favor option 2) because it's a clear choice to
satisfy user needs. And in the end that is what software development is
all about.
Regards,

Menno
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/iXGe9m/IbJq4o8sRArIZAKDA90w68DKlco/l

[freenet-CVS] freenet/src/freenet PeerPacketMessage.java,1.8,1.9

[Niklas Bergh]

Update of /cvsroot/freenet/freenet/src/freenet
In directory sc8-pr-cvs1:/tmp/cvs-serv25722/src/freenet

Modified Files:
PeerPacketMessage.java 
Log Message:
Yet an if(logDEBUG)

Index: PeerPacketMessage.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet/PeerPacketMessage.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- PeerPacketMessage.java  11 Oct 2003 20:00:14 -  1.8
+++ PeerPacketMessage.java  12 Oct 2003 15:06:25 -  1.9
@@ -134,9 +134,10 @@
  * @param detail the excuse exception
  */
 public void notifyFailure(SendFailedException detail) {
-   Core.logger.log(this, "notifyFailure("+detail+") for "+this,
+boolean logDEBUG = Core.logger.shouldLog(Logger.DEBUG,this);
+   if(logDEBUG) Core.logger.log(this, "notifyFailure("+detail+") for "+this,
detail, Logger.DEBUG);
-   Core.logger.log(this, "notifyFailure() for "+this,
+   if(logDEBUG) Core.logger.log(this, "notifyFailure() for "+this,
new Exception("debug"), Logger.DEBUG);
if(finished) {
Core.logger.log(this, "notifyFailure on "+this+" already finished!",

___
cvs mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/cvs

Re: [freenet-dev] Performance Increase

[Edgar Friendly]

Todd Walton <[EMAIL PROTECTED]> writes:

> 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

That's one of the frustrating things about debugging freenet.  There's
not necessarily any correlation between your node's stability/its
bugginess and its performance.  Thanks for letting people know there's
hope.

Thelema
-- 
E-mail: [EMAIL PROTECTED]Raabu and Piisu
GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7  84B7 D8D7 6ECE 3635 2AAB
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-CVS] freenet/src/freenet/crypt/ciphers Rijndael_Algorithm.java, 1.7, 1.8

[Edward J. Huff]

Update of /cvsroot/freenet/freenet/src/freenet/crypt/ciphers
In directory sc8-pr-cvs1:/tmp/cvs-serv6568

Modified Files:
Rijndael_Algorithm.java 
Log Message:
Added concurring comment.  No non-final fields in the class.
But allowing only one to run at a time on one CPU results
in fewer cache misses.


Index: Rijndael_Algorithm.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet/crypt/ciphers/Rijndael_Algorithm.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Rijndael_Algorithm.java 12 Oct 2003 09:19:37 -  1.7
+++ Rijndael_Algorithm.java 12 Oct 2003 13:15:04 -  1.8
@@ -505,6 +505,12 @@
 //I can see for it to be synchronized is that it will consume 100% CPU (due to
 //heavy calculations) when called. Probably should be unsynchronized if we
 //want better support for dual+ CPU machines. /Iakin 2003-10-12
+//Concur:  the class has no fields which are not final, and does
+//not reference fields of any other classes.  Control over how
+//many simultaneous makeKey invocations should be allowed is
+//a problem the callers should resolve among themselves.
+//It is a fact that allowing no more than one makeKey on any given
+//CPU will result in fewer cache misses.  -- ejhuff 2003-10-12
 public final static synchronized Object makeKey (byte[] k, int blockSize)
 throws InvalidKeyException {
 if (RDEBUG) trace(IN, "makeKey("+k+", "+blockSize+")");

___
cvs mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/cvs

Re: [freenet-dev] Re: [freenet-support] fproxy vulnerabilty?

[Tim McGrath]

On Sat, 2003-10-11 at 15:57, Toad wrote:
> 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)
> > > example:
> > > 
> > > ***end file.
> > 
> > Doesn't work. At least in unstable. Fixed months ago. Some idiot running
> > an ancient build.
> 
> Lee, you're not an idiot, whoever reported this on Frost was running an
> old build (perhaps as part of the "production network" ? :) ). I meant
> him.
*sigh* I haven't tested if prodnet has problems with this yet. I will
tonight.

Tim McGrath
(Hikaru)

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-CVS] freenet/src/freenet/crypt/ciphers Rijndael_Algorithm.java, 1.6, 1.7

[Niklas Bergh]

Update of /cvsroot/freenet/freenet/src/freenet/crypt/ciphers
In directory sc8-pr-cvs1:/tmp/cvs-serv31048/src/freenet/crypt/ciphers

Modified Files:
Rijndael_Algorithm.java 
Log Message:
Added a note about (almost) unncesseray synchronization

Index: Rijndael_Algorithm.java
===
RCS file: /cvsroot/freenet/freenet/src/freenet/crypt/ciphers/Rijndael_Algorithm.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- Rijndael_Algorithm.java 4 Mar 2003 20:27:35 -   1.6
+++ Rijndael_Algorithm.java 12 Oct 2003 09:19:37 -  1.7
@@ -501,7 +501,11 @@
  * @param blockSize  The block size in bytes of this Rijndael.
  * @exception  InvalidKeyException  If the key is invalid.
  */
-public static final synchronized Object makeKey (byte[] k, int blockSize)
+//TODO: This method doesn't really need synchronization. The only reason
+//I can see for it to be synchronized is that it will consume 100% CPU (due to
+//heavy calculations) when called. Probably should be unsynchronized if we
+//want better support for dual+ CPU machines. /Iakin 2003-10-12
+public final static synchronized Object makeKey (byte[] k, int blockSize)
 throws InvalidKeyException {
 if (RDEBUG) trace(IN, "makeKey("+k+", "+blockSize+")");
 if (k == null)

___
cvs mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/cvs

Re: [freenet-dev] Stable merge

[Niklas Bergh]

> Am I right in thinking upgrading to NGR wiped the old routing and loaded 
> new seeds? Was so long ago since I did it.

It will wipe the old rt (and use new seednodefs) yes.. 

/N

___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] More on 6229

[Mike Stump]

Ok, here are some more observations on 6229...  It is realatively
nice.  It doesn't reject, it finds stuff, and I, man does it find
stuff.  I'm seeing 36% success rates, before I was at 1-2%.  I have
not clue how it climbed so fast, so high.  It might be because I wiped
out my routing table and reloaded from a recent seeds file.  It is
sending out lots of good data.  Hop time went up from 6s to 10s.
Resets happen way to often, I have a 23MB backlogged outbound queue,
and I am resetting at 0.5!  No, no, no, I want resetting to trend down
to 0.02 just as soon as I have a 170 second backlog, immediately.
Just as soon as the backlog eases up, then trend the advertising up.
And inserts aren't going to work well, I have a feeling.  I see 0 that
worked out of 79 inbound tries.

It still dead locks and sits on a spin lock...


Now that we have something that might be closer to working, I'd like
to see people take a pause, work out the hot issues remaining, test
the network in the large with it, put it on on the stable branch, it
might be good enough already, before people break it.  After it is
snapped over, it would be good to have developers kick it hard, pay
attention to it, and rank the worse problems that are found, and fix
the top 3-7 problems, get those into stable, and then, stable will be
good for a while.  With that as a strong base, we can go back to fast
and furious development on unstable.  This would help with recent
events as well I think.
___
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl