On Tue, Oct 21, 2003 at 12:36:50AM +0100, Toad <[EMAIL PROTECTED]> wrote:
> > alas, fred is just a reference implementation, and in progress, too, so I
> > don't mind either, as the future will bring much good to the situation.
>
> Heh. Freenet cannot be run with free software (except maybe the non-nio
> branch), because Kaffe, GCJ and so on don't yet implement NIO.
Yes, but that's freenets fault, if any :) I just meant to say that,
while I accept the choice to write it in java (as I would have to accept
any other choice), that one of the official goals (portability) is far
from being reached. I'd go as far as to say that chosing java was a
particularly unportable choice, both years ago and now.
Again, I'm, not trying to flame freenet for using java, but I _do_ see
a gap between reality and the stated goals that confused me in the
beginning.
> > And frankly, my biggest problem was my node crashing or (worse) simply not
> > responding after a while. However, _when_ the node was working, I couldn't
>
> Interesting. Was there a specific bug that got fixed? Generally crashes
> would be JVM problems, hangs would be Fred problems...
On the list I saw discussion abot a particularly nasty jvm bug, which
seemed to happen here, too. But after that was fixed I didn't have a
crashing vm anymore.
The "node doesn't respond after a while" phenomenon is still there, but
it's constantly changing. During around 6200, the node simply stopped
responding on all ports (i.e. accepted connections but nothing was
happening). Nowadays the node seems to work for a few hours, then close
the connection or returning route not found.
The latest snapshot(s?) has this behaviour:
22:32:37 175: Net::FCP::Exception<<route_not_found,reason:No route found>>
i.e. route_not_found exceptions almost immediately, while some blocks
can still be fetched successfully. Also, it says:
Oct 24, 2003 10:47:55 PM (freenet.node.Node, main, NORMAL): Scheduling open on all 0
connections
where it formerly said 50 conenctions, which is probably connected to these
messages earlier:
Oct 24, 2003 10:47:38 PM (freenet.node.rt.NGRoutingTable, main, NORMAL): Rejecting
reference tcp/65.31.24.19:2115, sessions=1, presentations=1, ID=DSA(...) - too old in
loadEstimators
Well... that's live :)
> > initially used a higher priority for non-check-blocks, or blocks near the
> > beginning of a segment, but decided that this was a particularly bad idea.
>
> It is. We download the blocks *and the segments* in random order.
Well, and I download blocks and segments and files in random order... :)
> > is that when I request block n at HTL 15, then re-requesting it some
> > time later at HTL 0 _often_ succeeds. Which is far better than
> > randomly requesting other blocks.
>
> Hmm. That is strange. Perhaps the corruption bug... Also, why do you
> increase the HTL rather than starting at 25?
Because
a) fproxy and everybody else seems to do it, so unless I have good
reasons not to I should copy them, I though.
b) it is, as I said, much faster, often this happens:
- request a block at htl 25 => DNF
- wait some time (a long time)
- request a block at htl 0 => data
And the latter means that I can request, say, all 100 blocks of a
segment and, when going back to the file, quickly scan which blocks are
there already.
If I don't do this (and even _if_ I do this), then, caused by the random
download order, a block might already be in my node cache while my program
scans for other blocks not in the cache. This way I ensure that these
blocks get picked up quickly.
> > All this also means that, when a file finished, I often have more blocks
> > per segment then necessary to decode, as the blocks trickle in rather
> > rapidly and in bursts at htl 0 often.
>
> That is probably a good thing. It is equivalent to doing a little
> healing...
Ah, yes, healing :(
> > iver and over and even looked at the received data, and it does not seem
> > to be premature connection closing or short data related, as my client
> > detects this reliable (modulo bugs of course). Also, the corrupt data
> > often "looks" like real data, somehow scrambled (in an mpg for example).
>
> Is it related to restarts after some data has been transferred?
Hmm... do you mean that my client gets some data, gets a restart, and
receives more data? What my client is supposed to do is to forget any
data received so far on restarts. And this is also somewhat verified as
my client complains if it gets more data than it asked for.
I can't tell where in the file the corruption lies and wether restarts
were involved, when I have time I'll investigate more (by saving a few
corrupted/correct blocks).
> > This is not a serious problem for me either, I haven't lost a file
> > because of that yet. and the only serious showstopper (fcp on non-local
> > connections) has been fixed rather quickly.
>
> I thought it took ages to fix that one :)
Well, I might not be the first person to report that bug, so maybe it
*took* ages (being in 5028 already), but for me it was fixed quickly after
reporting it *g*
> > Probability of success of an incoming request
> > Oct 19, 2003 5:47:58 PM
> > 0 | 0.050851833
> > 1 | 0.044327572
> > 2 | 0.05563835
> > 3 | 0.04980033
> > 4 | 0.048084054
> > 5 | 0.04565902
> > 6 | 0.049584758
> > 7 | 0.04659147
> > 8 | 0.046026126
> > 9 | 0.04020678
> > a | 0.03921804
> > b | 0.039
> > c | 0.03987525
> > d | 0.046337817
> > e | 0.044974815
> > f | 0.043094557
>
> Woah. What build number?
That was 6257. I don't even know what these numbers mean exactly.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
