Vai al contenuto

Sincronizzazione

La sincronizzazione di bae è la sincronizzazione di coven: bae dichiara le proprie tabelle e blob, e coven fa il resto. Questa pagina è la meccanica per come si applica a bae; la documentazione di coven copre ogni pezzo in dettaglio.

coven possiede la connessione SQLite, quindi ogni scrittura che bae salva passa attraverso di esso. Quando viene salvata una transazione che modifica tabelle sincronizzate, coven registra ogni modifica di riga, con le colonne toccate, nella stessa transazione, così una modifica salvata non va mai persa, anche se l’app si chiude un attimo dopo. Niente diff, niente flag sporchi: la cattura è una proprietà della connessione, e una scrittura non può essere persa. La modifica attende sul dispositivo e viene cifrata e firmata solo quando viene inviata, quindi scrivere non richiede né chiave né rete.

Tutta la storia di una libreria nella home cloud è una sequenza numerata di oggetti. Ognuno contiene il lotto di modifiche di un dispositivo, una voce di amministrazione, una chiave sigillata per un membro o un annuncio di snapshot. Ogni dispositivo li applica in ordine e non ne salta mai uno, così ogni dispositivo concorda su cosa è successo e quando. Un dispositivo aggiunge l’oggetto successivo solo dopo aver applicato tutti quelli precedenti.

Un passaggio di sincronizzazione legge in avanti dall’ultimo oggetto applicato dal dispositivo finché ne manca uno, controlla la firma di ciascuno e lo applica, invia le modifiche in coda di questo dispositivo come un nuovo oggetto, poi fa il lavoro richiesto dal nuovo stato: condividere o revocare l’accesso, creare snapshot, eliminare la storia vecchia. Un passaggio su una libreria tranquilla costa due richieste, qualunque sia la sua dimensione.

I passaggi vengono eseguiti dopo modifiche locali, su un timer inattivo e subito con Sincronizza ora. I fallimenti vengono ritentati secondo un unico calendario di attesa, e tutto ciò che non può procedere indica cosa sta aspettando, cosa che bae mostra nella sua riga di stato della sincronizzazione.

Due dispositivi che modificano la stessa libreria mentre sono separati sono il caso normale, non l’eccezione. Quando le loro modifiche si incontrano:

  • Le modifiche a righe diverse o colonne diverse si applicano entrambe. Modificare l’anno di una release sul portatile e la sua etichetta sul desktop produce entrambi i risultati.
  • Le modifiche alla stessa colonna della stessa riga sono ordinate per marca temporale: vince la modifica più tarda, in modo deterministico e identico su ogni dispositivo.
  • Le eliminazioni vincono sulle modifiche concorrenti: una modifica fatta a una riga che nel frattempo è stata eliminata perde, quando che arrivi, così una release eliminata su un dispositivo resta eliminata anche se un altro dispositivo l’ha modificata nello stesso intervallo.

coven conserva ogni valore sostituito come valore perso; bae non ne mostra né ne scarta nessuno, quindi non c’è UI di conflitto. Ogni dispositivo converge allo stesso risultato da qualunque ordine di arrivo.

Un dispositivo che si unisce o ripristina non riproduce la storia dall’inizio. I dispositivi creano snapshot, lo stato completo della libreria a un punto della sequenza, e una volta che la libreria e ogni cerchia privata ne hanno uno, la storia precedente viene eliminata. Un nuovo dispositivo carica lo snapshot più recente, poi applica solo ciò che è venuto dopo. Un dispositivo rimasto assente più a lungo della storia conservata fa lo stesso, e conserva le sue modifiche non inviate.

Versioni dello schema

Link a questa sezione

Lo schema di bae è una sola migrazione, e ogni modifica che un dispositivo invia registra la versione dello schema con cui è stata fatta. Un dispositivo che raggiunge una modifica da uno schema più nuovo del proprio si ferma lì, non applicando nulla oltre, finché l’app non si aggiorna; niente viene perso e niente viene applicato male.

Più grossolana della versione dello schema è l’era di compatibilità: la revisione coven fissata dentro ogni binario. Due build sincronizzano solo dentro un’era; una rottura del formato su filo di coven è una nuova era e un aumento di versione major su ogni app. Prima di 1.0, ogni build è era zero e i formati cambiano senza migrazione.

Cosa vede il provider

Link a questa sezione

Il provider conserva modifiche, snapshot, record di appartenenza e file cifrati; può contare oggetti, osservare dimensioni e tempi e vedere quale account scrive ogni oggetto, ma non leggerne il contenuto. Ogni oggetto che un dispositivo tira viene verificato, firma e appartenenza, prima che qualcosa tocchi il database: l’archiviazione è una casella di posta passiva e non attendibile. Vedi Cifratura e Identità e appartenenza.