monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] nuskool & certs created after a revision


From: Lapo Luchini
Subject: [Monotone-devel] nuskool & certs created after a revision
Date: Fri, 02 May 2008 02:08:27 +0200
User-agent: Thunderbird 2.0.0.12 (X11/20080312)

Today I had a quick chat with Markus and Derek about nuskool and actually went and read gsync.cc and -to my surprise- I have to agree with 'em when they said "it's easy, really!".
I didn't really thought so at first.

OK. It transfers the DAG oh-so-nice, and cleverly so too. Then they told me about the problem with certs: either they are sent together the rev they refer to at once, or they never get sent later as the rev is never sent again.

And I proposed: what if a cert has a new 'time of creation' attribute containing the ID of one head at the time of creation (plus the ID of the revision they refer to, of course!). This way every time I send a revision I send not the certs that refer to it, but the certs that were created "at this time".

Then Dan said: if you do that way, it's ok if there's some new head to send, but if you:
a. add a new cert (linked to the head)
b. sync -> the cert gets sent
c. add a new cert (linked to the head)
d. sync again -> the new cert DOES NOT get sent again

And to this I have a new proposal: *after* the common core is found, it is sent each head (the "erase ancestors of the common core")
certs-value = sha1(all the certs created at the time of that node)

This way I only have, on each sync, to double-check the certs created at the time of the frontier, which as we well know is usually composed of only a few heads (1, 2, rarely more). Only for those head revisions on which the "certs-value" SHA1 doesn't match, we send all the certs again (or we may better refine, but they're usually little anyway, and it's only to be done on a few heads at most!).

The main "con" to this, except the small bandwidth overhead", is that each cert gets bigger by one ID size (both "referring ID" and "time ID")... so I wonder if there's a better way to avoid that; but that does at least *seem to work* to me. (of course, it seemed to me to work also without this final "frontier check", until Dan made me see the problem :P)

To all the interested people, I have only to say: nuskool doesn't bite, take a look at it... verily! =)

    Lapo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]