FEC downloading should abort as soon so many blocks fail that it wouldn't be possible to get enough to reconstruct the segment.
If it's not working that way, its a bug. Which segment does this happen on? Can you reproduce this problem with freenet.client.cl.Main? --gj "[EMAIL PROTECTED]" wrote: > >During a FEC retrieving, the attempt to recovery blocks > > continue in a situation that is sure to fail: > > > >the situation is when the number > > > >queued blocks minus > >recovered blocks (green check) minus > >unrecoverable block (red cross) > > > >is less that the number of blocks still > > necessary in the segment queue. > > > >It seems better to abort the transfert when > > not enought blocks remains. > > once upon a time, while i was watching those nice ok- and ick-,arg-,ooh!-signs > appear within my splitfileframe, i had the same idea. > > but i'm quite sure that aborting the unsuccessful download prematurely will not do > any good, because the last blocks that are requested for the garbage bin, > because the download will not succeed due too much missing blocks, will not be > requested and thus are not spread though freenet, making them drop off > the net, which will lead to even more missing blocks for the splitfile and the > following splitfile healing process! > > _______________________________________________ > devl mailing list > [EMAIL PROTECTED] > http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
