Re: [Monotone-devel] Re: Scalability question

[Nathaniel Smith]

On Sat, Aug 05, 2006 at 12:09:28PM -0700, Steven E. Harris wrote:
> Nathaniel Smith <address@hidden> writes:
> 
> > We simply maintain consistency during a sync -- we don't store a
> > revision until we have all the files it references, and we don't
> > store a cert until we have the revision it references.  An
> > interrupted sync can leave you with less complete information than
> > usual, but it's only by a matter of degree; nothing breaks.
> 
> Can you clarify whether an interrupted sync leaves anything new stored
> in the receiving database, or whether that data gets purged as part of
> a rollback? It sounds like you're saying two conflicting things: We
> only commit when the consistency checks indicate a complete
> transmission, but there's no problem with only winding up with part of
> what was supposed to be transmitted.

We only commit when we have a consistent state.  A consistent state
means, for instance, we don't have a revision in the database that is
missing some files, and no certs without a revision to put them on,
etc.

To make our life simpler, we always send stuff in such an order that
we can simply stream it straight to the db and consistency is always
maintained; that way we can simply hit "commit" at any time.

During transmission, we do hit "commit" from time to time, because if
something happens to break the transmission, it is useful that when
you re-run it, it can start again somewhere near where it left off.
Also, on the server side, it's multiplexing multiple client
connections against a single database, so if it only ever committed
when the database exactly matched the results of a _complete_
communication, then we could only commit when our client count dropped
to 0... and for a busy server, that might never, ever happen.

One place that we do commit in particular, though, is when a
transmission has completed, both sides do a commit before finishing
the disconnection.  This is mainly useful so you know, when you get
your prompt back on the client, that the server has not crashed at the
last moment and lost the stuff you just sent.

> I ask because we'll soon be designing a system at work that needs to
> be tolerant of interrupted transfers -- ideally avoiding
> retransmitting data already received -- and monotone may offer some
> hints in this area.

Well, merkle tries or the rsync algorithm to make transmissions
idempotent, plus content-addressing, make a _lot_ of issues go away, I
guess is my advice :-).

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff