On Friday 14 November 2008 10:04, Volodya wrote: > Somebody has asked me to send this (i will post the original in Russian and then > the translation done by me) (please note that i don't really think that all of > this makes sense, i'm an interpreter) > > == Translation == > Using of USK for the implimentation of ARK has obvious downfalls. One of them is > that during the rapid change of IP, for example during the change of the version > of the node or during the repeated connection loss, number of ARK increases > rapidly, and during this process there is no attempt to check if previous > versions are still accessible; and they can "fall out" from the network, if > almost instantaneously other nodes are restarting. As a result, as it seems, > quite often "breaks" in the sequence of ARK appear with the length of more than > 4 versions, which is a requirement for the working of normal USK; this leads to > the search for the "new" ARK number giving no results. This is especially > important for the nodes working less than 24 hours a day and having a dynamic IP. > One solution may be a request for ARK far ahead, say a few times with the random > increase of a version number from 5 to 100 related to the existing one (of > course distributed not equally, but maybe as a reverse exponent). Or a dumb > request for 44 rather than 4 following versions.
IMHO this is a weakness in USKs themselves, rather than a specific issue for ARKs. Solutions have been proposed but not yet implemented. IIRC we do look further ahead, but we throttle it increasingly heavily, so it takes a long time. > > Another bug problem of USK/SSK is related to the algorithm of attempting repeat > write to the existing SSK, when a specific version is provided. Node after > finding that another programme attempts to write SSK with the already existing > version immediately interrupts the request and notifies the programme. We attempt to find the data (via a USK fetcher). If it is already there and identical, we don't reinsert it. So it could be in the node's datastore and not on the network. > Unfortunately _ALL_ the programmes after that assume that information is already > on the network, and if no new information exists do nothing. In the best (but > not optimal) case they attempt to write the same information to the new version > of SSK. Correct behaviour of the programmes would be to ask the node for the > existing version of SSK in full and check the completeness and correctness of > the received, to exclude the existence of the unreadable SSK. In case of an > problem with the fetch of the data the need for the reinsert becomes clear. > Unfortunately even if one knows ahead of the time that the data has not changed, > programmes are forced to write a new version of SSK, or the node will once again > interrupt the request. > One optional solution may be the node allowing the rewrite of the current > version of SSK until it finishes successfully and only after letting the > programme know that the write has been successful as a rewrite of the data. > Or > beginning of the new request when programme asks the node how to behave if the > version already exists: repeat write (as the first solution), check the match > (the node, not the programme, asks for the current version and compares)or only > check the fetchability of the existing version of SSK (attempt to read SSK in > the full but without providing the data or writing it anywhere) - only check the > existence (or at least that there are enough blocks for full reconstruction). ARKs don't occupy lots of blocks. Having said that they do occupy one more block than necessary - for some reason we insert them with a text/plain mime type, they should be inserted with no MIME type. > This is important also for the working of ARK, as often restart of the node is > not a reason to reinsert the ARK version, but it is important that the existing > version is still in the network. Otherwise even neighbours working constantly on > the constant address: unchanged ARK of such a node can "fall off" the network, > but the node itself will not notice that even after the restart; but the > neighbours during the restart after changing IP will be unable to get that ARK. So basically, what you want is for the node to reinsert the ARK (at the old key) even if it is identical to the existing data. I dunno, maybe that's a good idea. It probably wouldn't get very far most of the time, because it would be terminated at the first node to have the data in its store... Anyone have a view? Other issues with ARKs and USKs: 1. ARKs are currently inserted with a MIME type, resulting in them occupying an SSK and a CHK. An SSK is all that is needed, and since I suspect we have overcapacity in SSKs, that should greatly improve ARKs' reliability. 2. It is hard to find the latest version of a USK when you've lost your place. IMHO the simplest, fastest, and most reliable solution to this is date-based hierarchical pointers (which would simply include the latest edition at a given time). Hence: USK at blah/site/12 -> SSK at blah/site-12 // the actual content But we also insert SSK at blah/site-___DATE___-2008 SSK at blah/site-___DATE___-2008-11 SSK at blah/site-___DATE___-2008-11-14 All of which contain the current edition number, "12". > > == End == > > -- > http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast > http://eng.anarchopedia.org/ Anarchopedia, A Free Knowledge Portal > http://www.freedomporn.org/ Freedom Porn, anarchist and activist smut > > "None of us are free until all of us are free." ~ Mihail Bakunin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/support/attachments/20081114/8c4089cf/attachment.pgp>
