> -----Original Message----- > From: devl-bounces at freenetproject.org > [mailto:devl-bounces at freenetproject.org] On Behalf Of Matthew Toseland > Sent: Thursday, April 23, 2009 3:17 PM > To: support at freenetproject.org; Discussion of development issues > Cc: Ian Clarke > Subject: [freenet-dev] Solving "I queued it 2 weeks ago and > it's still at0%" : are really long URIs a problem? > > Anecdotal evidence suggests that right now at least one third > of our content persistence problems boil down to this one > bug: "I added it 2 weeks ago and it still hasn't got past 0% > (0/1)". A new key type, DHKs (Duplicated Hash Keys), would > solve the problem, but the new keys would be twice as long as > current CHKs. Is this a problem? I would really appreciate > input from users, particularly those who upload and download files: > - Is it a problem for the keys to be really long (twice as > long as current CHKs)? CHKs are copied and pasted, so maybe > not a problem? > - Is it true that a great many downloads get stuck at 0% for > a long time, showing 0 blocks of 1 if you mouseover the percentage?
I think you should first of all figure out whether it isn't a db4o introduced bug or even a problem which has been there before db4o. Relying on something brand new (the db4o branch) which has been out in the real world only for some days to decide implementation of a new key type is really insane IMHO. We don't know whether the db4o branch doesn't have hundreds of other bugs. And in general the debugging of the node has been mostly on hold for long time due to your work on db4o. This would not be the first bug which makes downloads hang at 0% which we had. Further I do not understand why you don't want to solve the problem with tunnels. You told me that tunnels fix three problems: 1. they increase security 2. <toad_> well the other benefit is that it allows us to do bloom filter sharing [17:07:58] 3. tunnels would fix the top-block-not-reachable problem we are talking about So tunnels would fix 3 problems, this fixes 1 and tunnels will still be necessary some day. Why not just postpone the fix of the top-block-problem until we have tunnels? Why not make the node just automatically re-insert the top block upon download? Thats easy to implement after all? Why not debug first? I don't understand why you would want to chose the annoying alternative of implementing yet another key type if there are so many alternatives to it. > > Example: > CHK at 4~2FTXtBE2So8NZZIzneYrn5SOaFFk-hQsvjBHLc77A,97XjJekfSl8Hxk > JFYhj4cdo9n7s0exhE-EWMr8zuVxM,AAIC--8/chaosradio_142.mp3 > > -> (something like) > > DHK at 97XjJekfSl8HxkJFYhj4cdo9n7s0exhE-EWMr8zuVxM,4~2FTXtBE2So8N > ZZIzneYrn5SOaFFk-hQsvjBHLc77A,ughDyCjP0jeBuRRx33nULUb4Pl-6Dk9D > rDrH1miXCj0,VIOAKDzD~YIzrD5NBbD3v5SxOiwYXg84qQYdbkJA3bo,AAIC-- > 8/chaosradio_142.mp3 > > GORY DETAILS: > > Currently we use: > CHK@<routing key>,<crypto key>,<extra> > > (Filenames afterwards are manifests, and therefore impact on the CHK) > > The new key type would be: > > DHK@<data hash>,<routing key 1>,<routing key 2>,<routing key > 3>,<extra>/<ignore filename> > > (A filename is mandatory, and is always ignored, so does not > impact on the rest of the key). > > We might allow any number of routing keys from 2 upwards, for > more redundancy at the cost of a longer URI, but IMHO 3 is a > good default number. > > You would get such a key when you insert a file as DHK at . > > Arguably nobody ever types CHKs even now, and copy and paste > allows for fairly long keys. Thoughts? >
