2

I am implementing a distributed audio repository on which registered users can create audio recordings and share these with other registered users. Ideally we would like to run the repository on a few (n<5) laptops that are intermittently connected to a wireless mesh network. So repository nodes running couchdb would replicate with each other when connectivity is available. The repository will be situated in a rural village, which has no power infrastructure, so repository laptops are powered by solar panels and car batteries. In the past we have run into problems where laptop batteries drain completely resetting the computers clock to 0 -- January 1st, 1970. Internet connectivity is also very patchy and very expensive. Keeping in mind intermittent power and connectivity as well as very inaccurate clocks, I was wondering how best to sequence documents (or recordings) so that they roughly correspond to the chronology of when recordings were created on different repository nodes, both before and after replication. I would be very grateful for any help on how I could create a replicating by_date, by_sequence, by_chronology (or whatever you want to call it) view that could work within these constrained conditions. It doesn't have to be perfect, just good enough or better than a naive solution.

Thank you!

Thomas

Thomas
  • 665
  • 1
  • 6
  • 11

1 Answers1

1

Well, you could start by including a simple incrementing integer in each new document, by looking at the last number available in the database and taking the next one. This gets you a few things:

  • Consistent ordering for locally recorded segments in the absence of connectivity
  • After synchronization with other nodes, new segments will get a higher sequence number than all replicated segments

This will mean that you cannot piece together if sequence number 45 from one node was recorded earlier or later than sequence number 45 from another node, but it does let you piece together a directed acyclic graph, imposing at least a rudimentary ordering of the documents.

You could add a value representing the node on which the segment was recorded to make it even better.

djc
  • 11,603
  • 5
  • 41
  • 54