Larry Gadea | 2 Feb 03:19 2005
Picon

Freenet Error

Hey.

I double clicked on the icon in windows to open my webbrowser at the
Web Interface for FreeNet. I then clicked on the first portal. It said
that it couldn't find a route (1 node was polled). (normal procedure)
So I clicked retry. After a while, i check my window again, and i get
the following. Possibly a threading problem?

-----------
Couldn't retrieve key: SSK <at> rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/TFE//
Hops To Live: 17

Please report the following to devl@...:

freenet.client.WrongStateException: Wrong state: FAILED should be
DONE: null: Transfer failed with 75194 moved.

freenet.client.WrongStateException: Wrong state: FAILED should be
DONE: null: Transfer failed with 75194 moved.
	at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:312)
	at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
	at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)
	at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
	at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)
	at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
	at freenet.client.AutoRequester.onReachedState(AutoRequester.java:940)
	at freenet.client.AutoRequester.access$100(AutoRequester.java:32)
	at freenet.client.AutoRequester$AutoListener.onDone(AutoRequester.java:994)
	at freenet.client.listeners.DoneListener.receive(DoneListener.java:61)
	at freenet.client.AutoRequester$AutoListener.receive(AutoRequester.java:990)
(Continue reading)

Robert Hoehndorf | 2 Feb 14:10 2005
Picon

simple bug report

Hi,

i am having a lot of exceptions of the following kind, lately. It happens 
with all kind of different sites. 
If you need any more information regarding this bug, please let me know.

freenet.client.WrongStateException: Wrong state: FAILED should be DONE: null: Transfer failed with
121748 moved.

freenet.client.WrongStateException: Wrong state: FAILED should be DONE: null: Transfer failed with
121748 moved.
                                    at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:312)
                                    at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
                                    at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)
                                    at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
                                    at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)
                                    at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
                                    at freenet.client.AutoRequester.onReachedState(AutoRequester.java:940)
                                    at freenet.client.AutoRequester.access$100(AutoRequester.java:32)
                                    at freenet.client.AutoRequester$AutoListener.onDone(AutoRequester.java:994)
                                    at freenet.client.listeners.DoneListener.receive(DoneListener.java:61)
                                    at freenet.client.AutoRequester$AutoListener.receive(AutoRequester.java:990)
                                    at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java:55)
                                    at freenet.client.InternalClient$InternalFeedbackToken.unlockedProduceEvent(InternalClient.java:192)
                                    at freenet.client.InternalClient$InternalGetToken$TransferCompleteListener.receive(InternalClient.java:319)
                                    at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java:55)
                                    at freenet.client.SegmentOutputStream.close(SegmentOutputStream.java:227)
                                    at java.io.FilterOutputStream.close(Unknown Source)
                                    at freenet.support.io.FilterDataChunkOutputStream.close(FilterDataChunkOutputStream.java:23)
                                    at java.io.FilterOutputStream.close(Unknown Source)
(Continue reading)

Edgar Friendly | 2 Feb 20:39 2005
Picon

Re: Re: [freenet-dev] the htl thingy

Matthew Toseland <toad@...> writes:

> > good idea to simulate pdrop...
> 
> One further issue is that not having HTL means we have a flat timeout.
> This can be an advantage in terms of simpler code, but it is also a
> caveat because if the request goes on a long time we get the different
> nodes timing out at different times...

I was trying to figure out why bother having timeout on individual
requests, and not just having a timeout on the node's connection (so
that if it doesn't talk to us in a while, we figure it's died or
whatever).  The best reason I could come up with is that otherwise
it'd be easy for nodes to black-hole requests.

One solution to this (that fits well with my ideas of load balancing)
is to have a limit on simultaneous requests to a node, so that it'd be
able to filibuster (not reply to) requests as it sees fit at the cost
of significantly decreased load.  Some algorithms for adjusting this
limit so that nodes that responded slowly got a lower limit and
quicker/successful nodes got a greater limit would finish the load
balancing equation.

I admit that this doesn't really solve the problem of a single request
taking potentially forever, but a long and HTL-independent timeout
would suffice to make requests that seemingly got eaten by the network
end, so that their resources could be reclaimed.  Having a request
time out in this manner would be misconduct for the node it was routed
to.  Yes, the whole chain would be punished for the last node's eating
of the message, and yes, I know that negative trust doesn't work, but
(Continue reading)

Todd Walton | 4 Feb 00:16 2005
Picon

Re: simple bug report

Try sending to the support mailing list.

-todd

On Wed, 02 Feb 2005 14:10:17 +0100, Robert Hoehndorf
<leechuck@...> wrote:
> Hi,
> 
> i am having a lot of exceptions of the following kind, lately. It happens
> with all kind of different sites.
> If you need any more information regarding this bug, please let me know.
> 
> freenet.client.WrongStateException: Wrong state: FAILED should be DONE: null: Transfer failed with
121748 moved.
> 
> freenet.client.WrongStateException: Wrong state: FAILED should be DONE: null: Transfer failed with
121748 moved.
>                                     at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:312)
>                                     at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
>                                     at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)
>                                     at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
>                                     at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:324)
>                                     at freenet.client.GetRequestProcess.getNextRequest(GetRequestProcess.java:74)
>                                     at freenet.client.AutoRequester.onReachedState(AutoRequester.java:940)
>                                     at freenet.client.AutoRequester.access$100(AutoRequester.java:32)
>                                     at freenet.client.AutoRequester$AutoListener.onDone(AutoRequester.java:994)
>                                     at freenet.client.listeners.DoneListener.receive(DoneListener.java:61)
>                                     at freenet.client.AutoRequester$AutoListener.receive(AutoRequester.java:990)
>                                     at freenet.client.SimpleEventProducer.produceEvent(SimpleEventProducer.java:55)
>                                     at freenet.client.InternalClient$InternalFeedbackToken.unlockedProduceEvent(InternalClient.java:192)
(Continue reading)

Newsbyte | 4 Feb 15:32 2005

the htl thingy

"But Newsbyte just pulled the numbers out of the ether."

Happy to see you don't make hasty conclusions.

It might surprise you, but I actually did the trouble of searching for a 
formula that provided the numbers; but they do, indeed, require some 
previous knowledge of the former hops. Since that can't be done in the 
Freenet-system (without htl or something similar), I agree it is rather 
useless. It does not have to know that 7 hops have passed, but it does 
have to know what the last hop did (well, actually the knowledge of the 
number of hops) to calculate the %...but since no htl- like thingy is 
going to be implemented (and I agree that that on itself isn't a bad 
thing), it's futile to ponder any more on such formulas. The partent 
poster, thus, was right. :-)

Without a history, it is clear that any formula becomes rather not very 
dynamic, since every node has to treat it as being new and thus the % 
(chance) on each node stays the same (altough, ofcourse, you have the 
cumulative effect). Given these limits, I think your suggestion makes 
the most sense, albeit it's not entirely clear to me yet why you set the 
min at 2.5%. Has it actually been tested on the sims yet, whether or not 
it could/should be set lower or higher? Lowering it would make sure that 
the first 7 hops, which are - pragmatically spoken -  the most important 
in the small-world topology, stays under the 10%, for instance. It would 
also mean some requests take a while to finish....but is this really 
such a problem?
Matthew Toseland | 4 Feb 21:39 2005
Picon

Re: the htl thingy

We will implement HTL. Because we want to avoid causing major extra
variability which would slow down the estimator learning process.
However, we may go for a low probability of decrement at max HTL, so
that we have 10 HTL hops plus say 15 probabilistic drop hops.

On Fri, Feb 04, 2005 at 03:32:42PM +0100, Newsbyte wrote:
> "But Newsbyte just pulled the numbers out of the ether."
> 
> Happy to see you don't make hasty conclusions.
> 
> It might surprise you, but I actually did the trouble of searching for a 
> formula that provided the numbers; but they do, indeed, require some 
> previous knowledge of the former hops. Since that can't be done in the 
> Freenet-system (without htl or something similar), I agree it is rather 
> useless. It does not have to know that 7 hops have passed, but it does 
> have to know what the last hop did (well, actually the knowledge of the 
> number of hops) to calculate the %...but since no htl- like thingy is 
> going to be implemented (and I agree that that on itself isn't a bad 
> thing), it's futile to ponder any more on such formulas. The partent 
> poster, thus, was right. :-)
> 
> Without a history, it is clear that any formula becomes rather not very 
> dynamic, since every node has to treat it as being new and thus the % 
> (chance) on each node stays the same (altough, ofcourse, you have the 
> cumulative effect). Given these limits, I think your suggestion makes 
> the most sense, albeit it's not entirely clear to me yet why you set the 
> min at 2.5%. Has it actually been tested on the sims yet, whether or not 
> it could/should be set lower or higher? Lowering it would make sure that 
> the first 7 hops, which are - pragmatically spoken -  the most important 
> in the small-world topology, stays under the 10%, for instance. It would 
(Continue reading)

Matthew Toseland | 5 Feb 19:43 2005
Picon

Problems with 5101; priorities

I have many reports from users that 5101 sucks. Some of these seem
fairly solid, reproducible results. On the other hand a few users seem
satisfied with it. I have been trying to focus on 0.7 work lately. Now,
should I try to debug 5101, in preference to 0.7 work?
--

-- 
Matthew J Toseland - toad@...
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
_______________________________________________
Devl mailing list
Devl@...
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
Matthew Toseland | 5 Feb 19:55 2005
Picon

Java and crypto

Java provides hashes, and asymmetric crypto. Apparently it does not
provide symmetric crypto. Unless I have missed it? The benefits of using
the built-in code are:
- We don't have to maintain that code. Less total loc.
- Possibility of it being implemented natively by the JVM, while
  maintaining portability.
--

-- 
Matthew J Toseland - toad@...
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
_______________________________________________
Devl mailing list
Devl@...
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
Sebastian Spaeth | 5 Feb 20:01 2005
Picon

Re: Problems with 5101; priorities

Matthew Toseland wrote:
> I have many reports from users that 5101 sucks. Some of these seem
> fairly solid, reproducible results. On the other hand a few users seem
> satisfied with it. I have been trying to focus on 0.7 work lately. Now,
> should I try to debug 5101, in preference to 0.7 work?

I'd say go for .7. Could not somebody else take over the stable branch 
for bug-fix mode only (like the Linux 2.4 kernel)?

Seb
Nathan Johnson | 5 Feb 20:09 2005
Picon

Re: Problems with 5101; priorities

In my humble opinion,

Focus on 0.7 .
Depending on degree of severity of problems with build 5101:
	warn about it;
	deprecate it;
	rebuild a previous build as 5102.

Gmane