Tesi di laurea specialistica in Ingegneria Informatica

1. Università degli Studi di Trieste
Dipartimento di Architettura e Ingegneria
Corso di Studi in Ingegneria Informatica
Tesi di Laurea Specialistica
Analisi e sviluppo di un sistema collaborativo
simultaneo per la modifica di dati JSON
basato su Operational Transformation
Laureando:
Filippo MUSCOLINO
Relatore:
Prof. Francesco FABRIS
Correlatore:
PhD. Carlos KAVKA
ANNO ACCADEMICO 2017-2018

3. A mio padre

5. Indice
1 Sistemi collaborativi simultanei e concorrenza 1
1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Struttura e caratteristiche . . . . . . . . . . . . . . . . . . . . 2
1.3 Criticità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Gestione della concorrenza . . . . . . . . . . . . . . . . . . . . 4
1.5 Algoritmi ottimistici per il controllo della concorrenza . . . . 5
1.5.1 Three-way merge . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Differential synchronization . . . . . . . . . . . . . . . 7
1.5.3 Operational Transformation . . . . . . . . . . . . . . . 10
1.5.4 Conflict-Free Replicated Data Types (CRDT) . . . . . 11
2 Operational Transformation 13
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Consistenza e problematiche . . . . . . . . . . . . . . . . . . . 15
2.3 Modelli di consistenza . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Modello CC . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Modello CCI . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Funzioni di trasformazione . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Trasformazione inclusiva ed esclusiva . . . . . . . . . . 22
2.4.2 Proprietà di trasformazione . . . . . . . . . . . . . . . 23
2.4.3 Concorrenza parziale . . . . . . . . . . . . . . . . . . . 26
2.5 Algoritmi OT . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 dOPT e adOPTed . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Jupiter . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.3 GOT e GOTO . . . . . . . . . . . . . . . . . . . . . . 34
2.5.4 SOCT2 e SOCT3/4 . . . . . . . . . . . . . . . . . . . 37
2.5.5 SCOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.5.6 TIBOT e TIBOT 2.0 . . . . . . . . . . . . . . . . . . . 39
2.5.7 COT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.8 Google OT . . . . . . . . . . . . . . . . . . . . . . . . 42
2.6 Estensione a dati strutturati . . . . . . . . . . . . . . . . . . . 45
2.6.1 Trasformazioni su strutture ad albero . . . . . . . . . 47

6. 3 Progettazione 51
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Livello applicativo . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3 Livello OT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.1 Modello del documento . . . . . . . . . . . . . . . . . 54
3.3.2 Operazioni sul modello . . . . . . . . . . . . . . . . . . 55
3.3.3 Funzione di trasformazione . . . . . . . . . . . . . . . 56
3.3.4 Algoritmo di controllo . . . . . . . . . . . . . . . . . . 60
3.4 Livello di comunicazione . . . . . . . . . . . . . . . . . . . . . 63
3.4.1 Gestione disconnessione e riconnessione . . . . . . . . 64
3.4.2 Tipologia di operazioni . . . . . . . . . . . . . . . . . 67
3.5 Conversione di operazioni . . . . . . . . . . . . . . . . . . . . 71
3.5.1 Conversione da livello applicativo a livello OT . . . . . 72
3.5.2 Conversione da livello OT a livello applicativo . . . . . 78
4 Implementazione 81
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.3 Schema di funzionamento . . . . . . . . . . . . . . . . . . . . 84
4.4 Librerie esistenti . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.5 Valutazione del prototipo . . . . . . . . . . . . . . . . . . . . 88
5 Conclusioni 91
5.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2 Considerazioni finali dell’autore . . . . . . . . . . . . . . . . . 92

7. Introduzione
La diffusione del Web 2.0 ha portato a un impiego crescente di strumenti
per la creazione e la modifica di contenuti online direttamente all’interno
del browser: dagli elaboratori di testi, ai sistemi per l’editing grafico, la
possibilità di usufruire di tali servizi in un ambiente web-based ha aperto un
nuovo scenario nel campo della collaborazione. Sin da subito si è creato un
forte interesse intorno la possibilità di estendere tali ambienti all’utilizzo in
tempo reale tra più utenti, sancendo sostanzialmente la nascita di quelli che
oggi vengono definiti "sistemi di collaborazione simultanea".
La caratteristica peculiare che contraddistingue tali sistemi risiede nella
necessità di mantenere una consistenza finale tra i dati visualizzati, garan-
tendo al contempo alta responsività e indipendenza tra gli utenti: ciascun
utente può lavorare separatamente su una propria copia locale dei dati, sin-
cronizzando le modifiche con le altre copie remote in maniera trasparente e
simultanea.
Il mantenimento della consistenza in un sistema collaborativo è un pro-
blema che viene studiato da anni in letteratura e ha prodotto diversi risultati:
la soluzione più rilevante è rappresentata dalle Operational Transformation,
un noto insieme di tecniche ampiamente usato in sistemi collaborativi avan-
zati e geograficamente distribuiti, come ad esempio Google Docs.
L’obiettivo finale del presente lavoro di tesi è lo studio del mantenimen-
to della consistenza di un documento in formato JSON (JavaScript Object
Notation), in un sistema collaborativo simultaneo, sfruttando un approccio
di tipo Operational Transformation. Oltre al vincolo sul formato, si richie-
de che il sistema funzioni in un contesto ad alta latenza (come può essere
Internet) e che il documento venga memorizzato su un server. Per raggiun-
gere questo obiettivo si è deciso di effettuare uno studio approfondito sulle
fondamenta teoriche alla base delle tecniche di Operational Transformation,
oltre a un’analisi della correttezza degli algoritmi esistenti, nell’ottica di
progettare un sistema il più possibile corretto. Questo percorso ha condotto
alla realizzazione di un prototipo di sistema collaborativo che mantiene la
consistenza e soddisfa i requisiti richiesti.
Le motivazioni alla base del seguente lavoro nascono da un’attività di
ricerca, da parte del gruppo di Ricerca e Sviluppo presso Esteco S.p.A.,
i

8. mirata all’estensione delle funzionalità collaborative ad applicativi esistenti.
In particolare, uno dei contributi principali sarà l’applicazione delle tecni-
che in esame per l’editing di workflow di business process, in una modalità
web-based collaborativa.
Il processo che ha portato alla realizzazione del progetto finale è stato
strutturato secondo le seguenti fasi:
• Nel primo capitolo verranno illustrate le caratteristiche di un sistema
collaborativo simultaneo, andando a valutare quali siano attualmente
le tecnologie disponibili per il controllo della concorrenza
• Nel secondo capitolo si introdurrà la materia d’indagine da cui ha
avuto origine l’intero studio: le tecniche di Operational Transforma-
tion (OT). Verranno fornite le fondamenta teoriche e matematiche su
cui si basa la correttezza di un sistema OT, per poi passare in rasse-
gna le principali famiglie di algoritmi analizzandone caratteristiche e
soprattutto correttezza formale
• Nel terzo capitolo si definirà la fase di progettazione del sistema, po-
nendo l’attenzione su come siano stati integrati tra loro diversi con-
cetti esposti nel capitolo precedente. Si metteranno inoltre in luce le
problematiche affrontate e le soluzioni progettuali proposte
• Nel quarto capitolo si volgerà l’attenzione alla fase di attuazione del
prototipo, presentando uno schema dettagliato di funzionamento, ef-
fettuando una comparazione con le librerie esistenti e infine conducen-
do una valutazione su quanto sviluppato
• Nel quinto capitolo si conclude analizzando i risultati ottenuti, pro-
ponendo eventuali sviluppi futuri e rilasciando alcune considerazioni
finali riguardo al lavoro esposto
ii

9. Capitolo 1
Sistemi collaborativi
simultanei e concorrenza
1.1 Introduzione
Un sistema collaborativo è un sistema pensato per l’utilizzo da parte di due
o più utenti, dediti a un’attività comune, con la presenza di un’interfaccia
su un ambiente condiviso. La caratteristica principale che distingue questi
sistemi dai generici sistemi multi-utente risiede nella necessità di propaga-
re le modifiche di un utente agli altri utenti in tempi più ridotti possibile.
Ad esempio, i DBMS (DataBase Management System) e i sistemi operati-
vi time sharing supportano una modalità multiutente, tuttavia forniscono
pochissime notifiche legate all’attività degli utenti; se dunque un utente ese-
gue un’azione, gli altri utenti non sono in genere notificati riguardo l’azione
eseguita. Oltre a ciò, un sistema collaborativo richiede un’interfaccia com-
plessa per gestire l’attività di gruppo, oltre a una accurata gestione della
concorrenza [8].
L’obiettivo finale è costituito dalla possibilità, da parte di più persone
che lavorano su computer diversi, di effettuare modifiche a dati condivisi
che risiedono su un server. Queste modifiche sono sincronizzate tra tutti gli
utenti, senza la necessità da parte di un client di comunicare con il server
prima di effettuare una modifica (in particolare non vi è necessità di tecniche
di locking). Quando i dati in oggetto sono rappresentati da un documento
(testuale o in altri formati), il sistema viene definito editor collaborativo.
In generale gli editor collaborativi si dividono in due categorie: gli editor
collaborativi simultanei (Real-time Collaborative Editor o RCE) nei quali
diversi utenti apportano modifiche a un documento simultaneamente, e gli
editor collaborativi non simultanei, i quali non permettono modifiche dello
stesso documento nello stesso istante: quindi più simili a sistemi di control-
lo di versione (Version Control System o VCS). Un sistema VCS, infatti,
permette di tenere traccia delle modifiche apportate a un progetto nel cor-
1

10. so del tempo. In tal modo è possibile richiamare una specifica versione in
qualsiasi momento, riportare i singoli file o l’intero progetto a una versione
precedente, revisionare le modifiche e conoscere chi le ha apportate.
L’editing collaborativo ha portato a un livello superiore il lavoro di grup-
po, permettendo di condividere in tempo reale non solo documenti testuali,
ma anche codice sorgente di un software, note, fino ad arrivare a interfacce
più complesse. Il più famoso sistema di editing collaborativo è rappresen-
tato da Google Docs (attualmente integrato in Google Drive). Esso fornisce
funzionalità di collaborazione sia in maniera sincrona (modifiche in tempo
reale al documento), sia asincrona (basandosi su un sistema di versioning).
1.2 Struttura e caratteristiche
Strutturalmente un sistema collaborativo è costituito da un insieme di po-
stazioni connesse a una rete e utilizzate da un gruppo di utenti. Ogni utente
ha a disposizione un’interfaccia su un contesto condiviso (nel caso specifico:
un documento) che ne permetta la visualizzazione e la modifica in maniera
simultanea. Tipicamente esiste un’istanza del sistema per ciascuna postazio-
ne, e nel caso in cui sia presente un server centrale, un’istanza sul server. Il
documento condiviso viene spesso replicato in modo che ne esista una copia
locale su ciascuna postazione. Al fine di mantenere la consistenza tra le re-
pliche è necessario che tutte le istanze vengano sincronizzate mutualmente.
Per motivi di efficienza solo le azioni che portano a una modifica dello stato
vengono utilizzate per la sincronizzazione e sono chiamate operazioni. Ogni
operazione effettuata su una postazione viene propagata successivamente al-
le altre postazioni, dove verrà applicata sulla replica locale del documento
[37, 8].
Per quanto concerne i tempi due sono le grandezze che caratterizzano un
sistema collaborativo simultaneo: il tempo di risposta e il tempo di notifica.
Tali tempi costituiscono rispettivamente il tempo necessario all’interfaccia
per mostrare le modifiche effettuate dall’utente e il tempo necessario affinché
le modifiche di un utente vengano propagate agli altri utenti.
Grande importanza viene attribuita al tempo di risposta, che deve esse-
re ridotto al minimo. Anche nel caso di utenti che lavorano su postazioni
connesse a Internet, dove la latenza di trasmissione non ha caratteristiche
di tipo deterministico e potrebbe assumere valori elevati in determinate cir-
costanze, è necessario che l’interfaccia utente sia reattiva.
Le caratteristiche che deve soddisfare il sistema sono le seguenti [32, 8,
18]:
• Alta interattività: il tempo di risposta deve essere minimo, deve
essere pari al tempo di risposta su un equivalente sistema monoutente
non collaborativo
2

11. • Comunicazione in tempo reale: ogni utente deve essere notificato
in tempo reale delle operazioni effettuate dagli altri utenti
• Distribuzione: non necessariamente i partecipanti devono essere col-
legati sulla stessa rete locale
• Volatilità: i partecipanti possono entrare e uscire in qualunque mo-
mento della sessione di lavoro
• Interazioni prive di vincoli: i partecipanti in genere non seguo-
no uno schema prestabilito, non si può stabilire a quali informazioni
accederanno
• Alto focus: durante una sessione c’è un’alta probabilità di accessi in
conflitto, poiché i partecipanti lavorano e modificano gli stessi dati
• Consistenza: una volta che le operazioni sono state applicate e pro-
pagate, ogni utente deve poter visualizzare una versione consistente
del documento
1.3 Criticità
Una delle principali sfide nello sviluppo di un editor collaborativo simulta-
neo è rappresentata dalla quantità di azioni da parte dell’utente che vanno
registrate: non solo digitazione, ma anche operazioni di copia e incolla, spo-
stamenti di parti di testo, sostituzioni sono tutte azioni che vanno tenute
da conto. Ogni modifica cambia la relativa posizione delle modifiche suc-
cessive, perciò la perdita di una modifica (magari a causa di un pacchetto
perso) può portare a stati non corretti. Non è pertanto semplice mantenere
la convergenza in un ambiente simultaneo e collaborativo. Altri fattori van-
no tenuti in conto: riguardano l’interfaccia, la replica dei dati, la robustezza
del sistema e la risoluzione dei conflitti.
Interfaccia
È necessaria un’interfaccia WYSIWIS (What You See Is What I See) in
modo da mantenere la consistenza della sessione (ogni utente deve vedere
la stessa interfaccia, senza differenze, aggiornata e coerente). Ciò si può
ottenere solo riducendo al minimo il tempo di accesso e modifica ai dati e
di notifica di cambiamenti effettuati da altri utenti.
Replica dei dati
Dal momento che è richiesto di ridurre al minimo il tempo di risposta, in
genere i dati sono replicati per ciascun utente. In questo modo tutte le ope-
razioni che potrebbero potenzialmente rallentare il sistema vengono eseguite
3

12. localmente. In questo modo non avviene una comunicazione a ogni singola
azione effettuata (ciò avrebbe un effetto degradante sul tempo di risposta).
Robustezza
Oltre al classico requisito di robustezza (mantenere il funzionamento cor-
retto anche in caso di situazioni anomale, e ripristino della funzionalità in
caso di situazioni anomale) i sistemi di tipo collaborativo devono garantire
un secondo livello di robustezza legato agli utenti: la possibilità di entrare e
uscire dalla sessione in qualsiasi momento da parte degli utenti porta a ricon-
figurazioni del sistema o a possibili azioni inaspettate da parte dell’utente
(ad esempio una sessione interrotta all’improvviso).
Conflitti
La problematica più grande resta quella riguardante l’applicazione delle mo-
difiche provenienti da utenti remoti, dal momento che esse sono state genera-
te a partire da versioni del documento che non esistono in locale. Tali modi-
fiche potrebbero quindi entrare in conflitto con le modifiche locali applicate
dall’utente.
1.4 Gestione della concorrenza
In un contesto come quello rappresentato da un ambiente di tipo collabo-
rativo, dove più utenti hanno possibilità di leggere e modificare una risorsa
condivisa, la problematica principale a cui si deve far fronte è costituita dalla
gestione della concorrenza. Nel caso di sistemi simultanei, dove l’attenzione
è concentrata sulle prestazioni e la responsività, è stato necessario l’utiliz-
zo di strutture dati replicate. Ciò da un lato ha permesso di migliorare le
prestazioni in lettura sui dati, dall’altro ha portato con sé tutte le proble-
matiche relative alla sincronizzazione dei dati e alla gestione dei conflitti nel
caso di operazioni concorrenti.
La gestione della concorrenza può essere risolta con due tipologie di
approcci diversi: approcci di tipo pessimistico o approcci di tipo ottimistico.
Approccio di tipo pessimistico
Gli approcci di tipo pessimistico puntano alla prevenzione dei conflitti utiliz-
zando sistemi di locking e rendendo esclusivo l’accesso alla risorsa condivisa.
Ciascun utente, prima di poter effettuare una modifica, deve instaurare una
comunicazione con gli altri utenti del sistema o con un server centrale che
funga da coordinatore. Ciò implica che è necessario attendere una risposta
da parte degli altri utenti, prima che una modifica venga finalizzata. La
4

13. risorsa condivisa può essere quindi letta da più utenti contemporaneamen-
te, ma modificata solo da un utente per volta. Un approccio di questo tipo
porta con sé diverse problematiche come l’overhead legato alla richiesta e ot-
tenimento del lock. Oltre a ciò, è importante la granularità del sistema, cioè
quali risorse vadano bloccat; ad esempio, in un editor di testo, al momento
di inserire un carattere bisogna valutare se vada bloccato l’intero paragrafo,
la riga o le parole circostanti. Un approccio di questo tipo non è ovviamente
applicabile in sistemi di tipo simultaneo, nei quali si richiede che le modifiche
vengano effettuate e mostrate in tempo reale [1, 11, 23].
Approccio di tipo ottimistico
Le tecniche per il controllo della concorrenza di tipo ottimistico, a differen-
za del precedente approccio, non richiedono una comunicazione con gli altri
utenti, prima di poter applicare una modifica. Ogni utente applica una mo-
difica locale in maniera immediata e successivamente informa gli altri utenti
dell’azione. Nel caso in cui avvenga un conflitto tra modifiche di utenti di-
versi, un algoritmo di risoluzione dei conflitti si occuperà di compensare i
cambiamenti e portare tutti gli utenti a uno stesso stato finale. Meccanismi
di questo tipo sono già stati studiati in altri ambiti, come ad esempio nelle
basi dati. Essi vengono utilizzati nelle interfacce utente lato web, poiché il
protocollo HTTP è caratterizzato dall’assenza di stato e ciò rende complica-
to implementare meccanismi di lock (basti pensare che un utente potrebbe
lasciare aperta una pagina web, senza notificare all’applicazione che la tran-
sazione per la quale ha richiesto il lock è stata annullata).
Per quanto riguarda la risoluzione dei conflitti, il modo più semplice consiste
nell’utilizzo di una tecnica di rollback per riportare i dati a uno stato prece-
dente al conflitto e annullare quindi la modifica che ha generato il conflitto.
Ciò garantisce che i dati siano sempre validi e consistenti, tuttavia non è
applicabile per applicazioni in tempo reale: in tali contesti i conflitti sono
molto comuni e non è sufficiente riparare ogni volta gli stati sbagliati, senza
interferire con le performance del sistema. Per questo motivo sono state
studiate altre tecniche di tipo ottimistico che svincolano dalla necessità di
utilizzare rollback per risolvere i conflitti.
1.5 Algoritmi ottimistici per il controllo della con-
correnza
Gli algoritmi di tipo ottimistico per il controllo della concorrenza vengono
classificati tra algoritmi state-based e algoritmi operation-based. Gli algorit-
mi di tipo state-based sfruttano le informazioni riguardanti i differenti sta-
ti del documento, senza considerare le informazioni sull’evoluzione che ha
portato da uno stato all’altro. Esempi di questa tipologia sono il Three-way
5

14. merge (adottato da sistemi per il controllo di versione, come Subversion) e il
Differential Synchronization. D’altra parte, gli algoritmi di tipo operation-
based mantengono informazioni riguardo l’evoluzione tra i differenti stati
del documento. Per propagare lo stato, tra un documento e una sua co-
pia, è necessario replicare sulla copia le operazioni eseguite sul documento.
L’esempio principale di questa tipologia di algoritmi è dato dalla famiglia
delle Operational Transformation. Esiste infine una famiglia di strutture
dati che implementa sia algoritmi di tipo state-based che operation-based: i
Conflict-Free Replicated Data Types (CRDT).
1.5.1 Three-way merge
Gli algoritmi di tipo Three-way merge [11] si possono trovare nel sistema
di controllo versione Subversion (noto come SVN) e nelle prime versioni
di Google Docs [6]. Ogni utente lavora localmente sul proprio client ed è
presente un server centrale che si occupa di gestire i conflitti. Il processo
alla base è il seguente (si veda figura 1.1):
1. Il client invia il contenuto del documento al server
2. Il server estrae le modifiche effettuate dall’utente e le unisce a quelle
provenienti dagli altri utenti
3. Il server invia la copia aggiornata del documento al client
Client 1
doc
client2
doc
client1
copia
originale
nuova
versione
Client 2
Confronto
Server
Figura 1.1: Schema del Three-way merge
6

15. Se un utente ha applicato delle modifiche al documento, durante il pro-
cesso di sincronizzazione, il client è obbligato a ignorare la nuova versione
ricevuta e tentare nuovamente il processo di sincronizzazione. Un algo-
ritmo con queste caratteristiche non si adatta a un contesto collaborativo
simultaneo, specie se la latenza della rete è considerevole.
1.5.2 Differential synchronization
Differential Synchronization (DS) è un meccanismo di sincronizzazione di
tipo ottimistico e state-based. L’idea su cui si sviluppa l’algoritmo è di
utilizzare differenti cicli di sincronizzazione tra client e server. Le modifiche
vengono estratte effettuando una comparazione tra lo stato corrente del
documento e lo stato precedente, producendo ciò che viene chiamato diff.
Gli aggiornamenti al documento vengono in seguito propagati tra i vari client
sotto forma di diff (non viene inviato l’intero documento).
L’algoritmo è simmetrico tra client e server, è asincrono in quanto non
blocca l’utente, nel mentre che si attende una risposta dalla rete, e porta alla
convergenza delle varie repliche del documento. Inoltre, essendo state-based,
non richiede che i diversi client mantengano una cronologia delle modifiche
effettuate.
DS è stato utilizzato in passato nel progetto Mozilla Skywriter1, noto
in precedenza come Bespin: un framework web per la creazione e modifi-
ca di codice sorgente. Dal gennaio 2011 è stato incluso nei progetti ACE2
(Ajax.org Cloud9 Editor) e Cloud9 IDE3 di Amazon.
Esistono tre diverse architetture che usano un algoritmo DS: DS Com-
mon Shadow, DS Dual Shadow e DS Guaranteed Delivery.
DS Common Shadow
Sono presenti due copie del documento, una lato client (Client Text) e una
lato server (Server Text), oltre a una copia comune (Common Shadow);
inizialmente tutte le copia hanno lo stesso contenuto. Le copie sul client
e sul server possono essere modificate in qualsiasi momento. L’obiettivo è
di ridurre al mimino le differenze tra queste copie. Il funzionamento è il
seguente (si veda figura 1.2):
1. La copia client (Client Text) viene confrontata con la copia comu-
ne (Common Shadow), generando una diff che conterrà le modifiche
effettuate sul client
1
https://github.com/mozilla/skywriter
2
https://ace.c9.io/
3
https://aws.amazon.com/it/cloud9/
7

16. 2. Viene sovrascritta la copia comune con il contenuto della copia client.
Dal momento che, durante la fase di sincronizzazione, la copia client
potrebbe essere modificata, solitamente si effettua uno snapshot del
contenuto prima della fase di comparazione.
3. Le modifiche contenute nella diff vengono applicate, sotto forma di
patch, sulla copia mantenuta dal server (Server Text). A questo punto
il processo diventa simmetrico nella direzione opposta: la copia server
viene confrontata con la copia comune, vengono generate la diff e le
modifiche applicate sulla copia client, sotto forma di patch. Il processo
si ripete a oltranza fino a raggiungere uguaglianza tra le tre copie.
Client
Text
Diff Patch
Patch Diff
Common
Shadow
Server
Text
Modifiche
Modifiche
Figura 1.2: Schema base del DS Common Shadow
DS Dual Shadow
Il DS Common Shadow è la forma più semplice di Differential Synchro-
nization, ma non può essere applicato in un’architettura client/server, dal
momento che la copia comune è condivisa. Per estendere l’applicabilità al
caso client/server è necessario utilizzare due copie comuni: una sul client
(Client Shadow) e una sul server (Server Shadow) (si veda figura 1.3).
Un problema rilevante è costituito dal caso in cui avvenga una tempora-
nea disconnessione dalla rete e venga perso un pacchetto. In tale circostanza,
al momento della riconnessione, è necessario riportare le due copie comuni
allo stesso contenuto: ciò si può effettuare solo inviando (in una direzione o
nell’altra) l’intero contenuto del documento, perdendo tuttavia le modifiche
effettuate durante l’assenza di connessione.
DS Guaranteed Delivery
Per risolvere i problemi dovuti a eventuali disconnessioni è stata introdotta
una versione più complessa, chiamata DS Guaranteed Deliver. Il proces-
8

17. Client
Text
Diff
Patch
Patch
Diff
Client
Shadow
Server
Text
Modifiche
Server
Shadow
Patch
Modifiche
Patch
Client Server
Figura 1.3: Schema base del DS Dual Shadow
so alla base è simile a quello del DS Dual Shadow, con la differenza che,
nel caso di perdita di un pacchetto, le modifiche vengono accodate in uno
stack e ritrasmesse al server, finché quest’ultimo non restituisce un segnale
di avvenuta ricezione. Per ottenere ciò, il server mantiene un’ulteriore co-
pia comune, oltre alla Server Shadow, detta Backup Shadow (come si può
vedere in figura 1.4). Essa contiene l’ultima versione precedente l’invio delle
modifiche, nel caso in cui il client abbia perso la connessione e non abbia
ricevuto l’ultimo pacchetto.
Client
Text
Diff
Patch
Patch
Diff
Client
Shadow
Server
Text
Modifiche
Server
Shadow
Patch
Modifiche
Patch
Client Server
Backup
Shadow
Figura 1.4: Schema base del DS Guaranteed Delivery
9

18. Differential Syncronization e sistemi simultanei
Gli algoritmi di Differential Synchronization, in quanto state-based, non so-
no generalmente adatti a contesti di comunicazione in tempo reale [1]. Ogni
qualvolta viene generata una singola modifica, andrebbe infatti effettuata la
comparazione tra le varie versioni del documento e ciò risulterebbe in un’e-
levata complessità temporale. Basti pensare a un editor di testo: per ogni
carattere inserito, andrebbe effettuato un ciclo di sincronizzazione scorrendo
l’intero documento alla ricerca delle modifiche. Per tale motivo, in ambienti
simultanei sono preferibili algoritmi di tipo operation-based.
1.5.3 Operational Transformation
Gli algoritmi della famiglia delle Operational Transformation sono di tipo
operation-based: sono orientati quindi alle azioni effettuate dall’utente e non
all’intero stato del documento. In un sistema OT, ogni client ha a disposi-
zione la propria copia locale del documento, sulla quale può operare senza
vincoli o meccanismi di locking. Nel momento in cui viene effettuata una
modifica, essa viene propagata agli altri client con i quali il documento è
stato condiviso. L’idea alla base delle OT è di trasformare (sostanzialmente
correggere) i parametri di un’operazione, in accordo agli effetti delle ope-
razioni concorrenti eseguite in precedenza: in questo modo si mantiene la
consistenza del documento.
Nell’esempio in figura 1.5 si intuisce il principio di fondo: due client
C1 e C2 mantengono una copia dello stesso documento condiviso (il cui
contenuto iniziale è la stringa "ABCD"). Su ciascun client viene generata
un’operazione sul documento (su C1 l’utente elimina il primo carattere "A",
su C2 viene eliminato il terzo carattere "C"). La posizione delle operazioni
indica un carattere all’interno del documento, a partire dalla posizione 0.
Una volta eseguite le operazioni, esse vengono propagate: sul client C1,
l’eliminazione del carattere "A" ha conseguentemente modificato la posizione
degli altri caratteri. Quando viene ricevuta la richiesta di eliminazione del
terzo carattere, viene eliminato "D" e non "C". Sul client C2, l’operazione
inviata da C1 resta corretta, poiché la posizione di "A" è rimasta invariata.
Il risultato finale è che le copie presentano un contenuto differente.
Nel caso OT, invece, al momento della ricezione dell’operazione su C1, si
verifica l’effetto dell’operazione applicata in precedenza: l’operazione prece-
dente ha ridotto di una unità la posizione di tutte le lettere. A questo punto
è presente un conflitto, perciò l’operazione viene trasformata (da Del(2)
diventa Del(1)) e successivamente applicata. Su C2, invece, l’effetto dell’o-
perazione precedente non influisce con l’operazione ricevuta, quindi non c’è
conflitto e si può applicare direttamente l’operazione. Il risultato finale è lo
stesso contenuto su entrambe le copie.
10

19. C1 C2
O2 = Del(2)
ABCD
ABD
O1 = Del(0)
BCD
BC
ABCD
BD
O2 = Del(2) O1 = Del(0)
C1 C2
O2 = Del(2)
ABCD
ABD
O1 = Del(0)
BCD
BD
ABCD
BD
O2' = Del(1) O1 = Del(0)
(1)
(2)
Figura 1.5: Differenza tra sistema senza OT (n.1) e con OT (n.2)
1.5.4 Conflict-Free Replicated Data Types (CRDT)
Un approccio più recente, rispetto alle OT, è dato dalla famiglia di strutture
dati CRDT [28, 1]. A differenza degli algoritmi OT, gli algoritmi alla base
dei CRDT non richiedono né di mantenere una cronologia delle operazioni,
né di effettuare un controllo della concorrenza, poiché sono stati proget-
tati per raggiungere nativamente la convergenza; ciò si ottiene a patto di
sottostare a determinati vincoli.
La famiglia dei CRDT prevede sia algoritmi di tipo state-based (Con-
vergent Replicated Data Type o CvRDT), sia di tipo operation-based (Com-
mutative Replicated Data Type o CmRDT).
Il principio alla base di una struttura CvRDT è che ogni replica applica
le modifiche ricevute dal client modificando il proprio stato locale; in seguito
(non immediatamente), essa invia il suo intero stato a una qualsiasi altra
replica presente nel sistema. Quando una replica riceve lo stato di un’altra
replica, applica una funzione di merge: viene unito il proprio stato con
11

20. quello ricevuto. Il processo si ripete a oltranza, finché ogni aggiornamento
è stato propagato su tutte le repliche. Viene dimostrato che le repliche
convergono allo stesso valore, utilizzando una funzione di merge che deve
essere idempotente, associativa e commutativa [28].
D’altra parte, nel caso di strutture CmRDT, una replica non invia a
un’altra replica il proprio stato per intero; invece, propaga a tutte le altre
repliche l’operazione appena generata. Ogni replica che riceve un’opera-
zione si occuperà di applicarla al proprio stato locale. Dal momento che
repliche diverse potrebbero ricevere operazioni diverse, in ordine differente,
è necessario che le operazioni siano commutative, quindi che sia possibile
trascurare l’ordine in cui le operazioni vengono applicate. Ovviamente biso-
gna controllare che le repliche non ricevano operazioni duplicate (scegliendo
un opportuno canale di comunicazione e/o prevedendo tecniche per il con-
trollo dei duplicati).
La possibilità di supportare la convergenza in maniera nativa è un grosso
vantaggio di questo tipo di strutture, tuttavia esistono alcuni contro: per
questo motivo nello sviluppo di editor collaborativi si è spesso preferito l’ap-
proccio di Operational Transformation. I vincoli sulla natura commutativa
delle operazioni e sulle caratteristiche della funzione di merge contribui-
scono ad aumentare la complessità dell’implementazione. Molti algoritmi
di tipo CRDT sfruttano inoltre la tecnica dei tombstone: quando avviene
un’operazione di eliminazione, l’elemento non viene fisicamente rimosso, ma
semplicemente marcato come tale. In questo modo è più facile gestire ope-
razioni concorrenti che includono rimozione di elementi, tuttavia aumenta la
complessità spaziale e viene a essere necessaria la presenza di un meccanismo
di garbage collector (come messo in evidenza in [28]).
Ciò non vuol dire che non sia possibile realizzare una struttura CRDT
in un contesto di editing collaborativo. M. Kleppmann e A. R. Beresford
in [17] propongono un esempio di CRDT per la modifica di dati in formato
JSON. Analizzando le regole di creazione e applicazione delle operazioni, si
intuisce l’elevata complessità del sistema; inoltre, anche in questo caso, va
implementato a parte un meccanismo di garbage collector.
12

21. Capitolo 2
Operational Transformation
2.1 Introduzione
Con il termine Operational Transformation (OT) si definisce una famiglia di
algoritmi di tipo ottimistico per la gestione della concorrenza, in particolare
per quanto concerne la modifica di documenti in ambienti collaborativi in
tempo reale. Più in generale, il termine viene utilizzato per indicare un
sistema che fa uso di tale tecnologia, nel suo complesso.
Tutti i sistemi OT mantengono un’architettura con elementi comuni:
un insieme di utenti connessi tra di loro tramite una rete di comunicazione
(affidabile per ipotesi), una fonte dati condivisa replicata su diversi client
(chiamati siti), la possibilità di generare, ricevere ed eseguire operazioni ri-
guardanti modifiche ai dati. L’obiettivo è il mantenimento della consistenza
tra le varie repliche. Non vengono utilizzati meccanismi di locking, i da-
ti sono sempre accessibili e non vengono bloccati. La struttura può essere
completamente distribuita, come nel caso del primo algoritmo dOPT [8]
o prevedere la presenza di un server centrale che funga da coordinatore,
come introdotto dall’algoritmo Jupiter [23]. La natura dei dati condivisi
fu inizialmente limitata al semplice documento testuale. Successivamente
si svilupparono sistemi più complessi, in grado di gestire dati strutturati
(es. un nodo HTML, un documento XML, un oggetto CAD), permettendo
l’applicazione di meccanismi OT anche in nuovi ambiti, quali ad esempio
l’editing grafico collaborativo.
Altra caratteristica comune dei sistemi OT riguarda la gestione delle
operazioni: ogni utente eseguendo una modifica genera un’operazione (es.
nel caso di un editor testuale, l’inserimento o la rimozione di un carattere
in una determinata posizione): essa viene applicata immediatamente sulla
copia locale, in modo da garantire la responsività necessaria in contesti co-
me quello simultaneo. L’operazione viene poi propagata agli altri utenti del
sistema: ciò può avvenire in maniera immediata o ritardata, a seconda di
come l’algoritmo gestisce l’ordinamento delle operazioni. Quando un utente
13

22. riceve un’operazione, è possibile che la modifica da applicare entri in conflit-
to con altre modifiche applicate in precedenza: in tal caso viene applicata
una trasformazione dell’operazione con l’obiettivo di risolvere la situazione
conflittuale che si è creata.
Come si può vedere, sono diverse le responsabilità di un sistema OT:
esso dovrà occuparsi sia di quali operazioni vadano applicate e trasforma-
te, sia della loro trasformazione nel caso di conflitti. Per questo motivo
generalmente si descrive un sistema OT dividendolo in due componenti:
• algoritmo di controllo: una componente di alto livello che descrive
l’ordine di applicazione e trasformazione delle operazioni
• funzione di trasformazione: una componente di basso livello che de-
scrive come vengono modificate le operazioni in caso di conflitti
La correttezza di entrambe le componenti viene specificata in un set di
proprietà e condizioni da soddisfare: ciò che viene chiamato modello di con-
sistenza. Esistono diversi modelli, proposti nel corso degli anni parallela-
mente all’evoluzione dei diversi algoritmi OT. Inizialmente la correttezza di
un sistema si basava sul mantenimento di un ordine causale delle operazioni
(causality preservation) e sul raggiungimento dello stesso contenuto su cia-
scuna replica (convergence). Progressivamente sono stati introdotti concetti
relativi al contesto su cui si sta operando, all’intento di un’operazione e alla
possibilità di annullare l’effetto di un’operazione già applicata (ciò che viene
definito undo).
Il primo algoritmo presentato in letteratura è quello proposto da C. A.
Ellis e S. J. Gibbs [8] nel 1989, sviluppato per ottenere convergenza in un edi-
tor testuale collaborativo chiamato GROVE (GRoup Outline Viewing Edit).
Da allora sono passati trent’anni di ricerca che hanno portato a molteplici
varianti di algoritmi OT, supportando funzionalità quali undo/redo, compo-
sizione e compressione delle operazioni, modifica di documenti strutturati.
Si è arrivati al punto in cui la loro applicazione è stata estesa ai sistemi
collaborativi non testuali. Tutti questi algoritmi sono stati applicati in vari
progetti, tra cui alcuni editor collaborativi come Etherpad1, Subethaedit2,
Google Docs3, ma anche in soluzioni non limitate all’editing di documenti
come il caso dell’IDE di Amazon Cloud94 o del software di modellazione 3D
CoMaya5.
1
http://etherpad.org/
2
https://www.codingmonkeys.de/subethaedit/
3
https://docs.google.com/
4
http://c9.io/
5
http://cooffice.ntu.edu.sg/comaya/
14

23. Nel corso del capitolo verranno illustrati i modelli principali, analizzan-
do quali meccanismi siano stati attuati dai diversi algoritmi OT al fine di
rispettare le proprietà presenti nel modello di riferimento.
2.2 Consistenza e problematiche
Nel momento in cui più utenti generano in maniera concorrente operazioni
diverse, nascono alcune problematiche che vanno affrontate. In particolare,
il sistema di riferimento è in tempo reale e i vari siti sono connessi da un
sistema di comunicazione non deterministico, di cui non è possibile stabilire a
priori la latenza (il caso di una rete internet). Uno scenario del genere mette
in luce tre principali problemi di inconsistenza che possono avere origine:
divergenza, violazione della causalità e violazione dell’intento [33, 34, 37].
Si consideri un esempio di tre siti connessi tra di loro tramite rete in-
ternet (senza la presenza di un server centrale), dove vengono generate tre
operazioni: O1 dal sito S1 e O2 e O3 dal sito S2 (si veda figura 2.1).
Un’operazione può essere l’inserimento o la rimozione di un carattere (si
considera il testo come insieme di caratteri ciascuno con una posizione, a
partire dall’indice 0). Si vanno ad analizzare i singoli problemi che possono
verificarsi.
Sito 2 Sito 3
O2
Sito 1
O1
O3
O2
O3
O1 O2
O3
O1
Figura 2.1: Sessione collaborativa tra tre utenti
Divergenza Ogni operazione è stata generata e applicata in locale im-
mediatamente dopo la generazione, successivamente è stata propagata agli
altri siti connessi alla rete. La conseguenza di questo schema è che opera-
zioni diverse possono arrivare su siti diversi in ordine differente, portando a
15

24. una divergenza dei risultati finali. Come si può vedere, sul sito 1 vengono
eseguite le operazioni O1, O2, O3, sul sito 2 vengono eseguite O2, O1, O3,
mentre sul sito 3 O2, O3, O1.
Si consideri, ad esempio, un documento iniziale condiviso vuoto e si
ipotizzi che le operazioni siano O1 "inserimento di ’A’ in posizione 0", O2
"inserimento di ’B’ in posizione 0" e O3 "inserimento di C in posizione 1". I
risultati sui siti 1, 2 e 3 sarebbero rispettivamente "BCA", "ACB" e "ABC".
Violazione della causalità Il secondo problema non riguarda diretta-
mente il risultato finale, piuttosto il processo di modifica che porta al ri-
sultato. Dal momento che le operazioni vengono eseguite in ordine non
deterministico, è possibile che venga perso il naturale rapporto causa-effetto
nell’ordine delle operazioni. Ritornando all’esempio precedente, si noti co-
me l’operazione O3 viene generata sul sito 2 dopo l’arrivo dell’operazione
O1, quindi l’utente sul sito 2 ha generato O3 conscio dell’effetto di O1 sul
documento. Questo implica che O3 potrebbe dipendere da O1. Sul sito 3,
tuttavia, le operazioni arrivano in ordine inverso (O3, O1): è quindi possi-
bile che l’utente sul sito 3 visualizzi l’effetto (O3) prima di visualizzarne la
causa da cui dipende (O1).
Si consideri ad esempio che O1 sia la domanda "In quale anno cadde il
muro di Berlino?" e O3 sia li risposta "1989". L’utente sul sito 3 vedrebbe
inserita la risposta prima della domanda.
Violazione dell’intento Il terzo problema riguarda il rapporto tra l’ef-
fetto di un’operazione, al momento della sua generazione e l’effetto attuale,
al momento in cui viene eseguita. Nell’esempio in questione, l’operazione
O1 è stata generata prima di venire a conoscenza dell’operazione O2, e vi-
ceversa, quindi O1 e O2 sono due operazioni indipendenti. L’operazione O2
è quindi nata con l’intento di essere applicata su un documento in un deter-
minato stato, privo dell’effetto di O1. Sul sito 1 O2 viene applicata dopo
aver applicato O1, quindi lo stato su cui viene applicata è stato modificato
dall’effetto di O1, è uno stato che non era previsto al momento di generare
O2. Quel sito al momento di eseguire O2 deve tenere conto dei cambiamenti
effettuati da O1 in modo da rispettare l’intento dell’utente che ha generato
O2.
Si consideri ad esempio che il documento iniziale contenga la stringa
"ABCDE" e che le operazioni siano O1 "inserimento di 89 in posizione 1" e
O2 "eliminazione di 2 caratteri dalla posizione 2" (in questo caso la stringa
"CD"). Il risultato finale che ci si aspetta è "A89BE". Sul sito 1, dopo
l’esecuzione in sequenza di O1 O2 il risultato che si ottiene è "A8CDE" che
è in contrasto sia con l’intento di O1 (il 9 non è presente), sia con l’intento
di O2 (la C è ancora presente).
16

25. Ulteriori problemi Oltre ai problemi di inconsistenza descritti in prece-
denza, è importante notare come possano sorgere altri problemi che ad ogni
modo non riguardano direttamente i sistemi di controllo della concorrenza.
Un esempio è dato da un testo con un errore sintattico: si prenda ad esem-
pio "lato adiacenti". Un utente sul sito 0 potrebbe correggere il documento
modificando la "o" di lato in "i"; un altro utente sul sito 1 potrebbe invece
modificare l’ultima "i" di "adiacenti" in "e". Il risultato finale sarebbe "la-
ti adiacente", che presenta ancora un errore sintattico. Problemi di questo
genere possono essere risolti solo da meccanismi esterni all’applicazione.
2.3 Modelli di consistenza
La necessità di specificare quali problemi vengano risolti e come venga otte-
nuta la consistenza, da parte di un determinato algoritmo, porta alla crea-
zione di un modello di consistenza. Esso definisce le proprietà che un sistema
di controllo della concorrenza deve soddisfare, al fine di mantenere la con-
sistenza del sistema stesso. Nel caso degli algoritmi OT sono stati diversi
i modelli proposti nel corso degli anni: con l’evoluzione e l’introduzione di
nuovi algoritmi sono stati introdotti progressivamente nuovi modelli. Nel
corso di questo capitolo verranno mostrati i due modelli più importanti,
nonché primi in ordine cronologico, su cui si basano i principali algoritmi di
Operational Transformation.
Prima di definire i modelli proposti è necessario specificare alcune defi-
nizioni che verranno utilizzate all’interno dei modelli: la relazione di ordine
causale (introdotta da Lamport [20] nel 1978) e la definizione di intento di
un’operazione (considerata per la prima volta nel 1996 [32, 33]).
Definizione 2.3.1 (Relazione di ordine causale). Date due operazioni Oa
e Ob, generate rispettivamente sui siti i e j, allora Oa → Ob (Oa precede
causalmente Ob) se e solo se vale una delle seguenti:
1. i = j e la generazione di Oa è avvenuta prima della generazione di Ob
2. i = j e l’esecuzione di Oa sul sito j è avvenuta prima della generazione
di Ob
3. esiste un’operazione Ox tale che Oa → Ox e Ox → Ob
Data la definizione precedente, se vale Oa → Ob si dice che Oa precede
causalmente Ob (o Ob segue causalmente Oa). Si dice inoltre che Ob è di-
pendente da Oa. Analogamente se non vale né Oa → Ob né Ob → Oa si dice
che Oa e Ob sono indipendenti (o concorrenti) e si indica con Oa||Ob.
Definizione 2.3.2 (Intento di un’operazione). Data un’operazione O, si
dice intento dell’operazione O l’effetto dell’esecuzione di O sul documento
condiviso nello stato osservato dall’utente al momento di generare O.
17

26. 2.3.1 Modello CC
Il primo modello proposto da C. A. Ellis e S. J. Gibbs [8] nel 1989 è il
modello CC (Causality Convergence), basato su due proprietà.
Definizione 2.3.3 (Preservazione causale). Data una coppia di operazioni
Oa e Ob, se Oa → Ob (Ob è dipendente da Oa) allora su ogni sito l’esecuzione
di Oa avviene prima dell’esecuzione di Ob.
Definizione 2.3.4 (Convergenza). Quando la sessione del sistema si trova
in uno stato di quiescenza, le copie del documento condiviso su tutti i siti
sono identiche.
La prima proprietà, chiamata originariamente proprietà di precedenza
(precedence property [8, 25]) e successivamente di preservazione della cau-
salità (causality preservation [33]) punta a mantenere l’ordine causale del-
le operazioni. Essa assicura la consistenza dell’ordine di esecuzione delle
operazioni causalmente dipendenti su tutti i siti.
La seconda proprietà, la proprietà di convergenza (convergence), defini-
sce quale sia lo stato da ottenere quando il sistema è quiescente, cioè quando
tutte le operazioni generate sono state eseguite su tutti i siti (non esistono
quindi richieste in transito o in attesa di essere eseguite).
Secondo il modello CC un sistema collaborativo può definirsi corretto se
e solo se entrambe le proprietà sono sempre soddisfatte.
È importante notare come le due proprietà siano tra loro indipendenti
[8]. Un semplice esempio è dato dal caso di due operazioni indipendenti
tra di loro. Si consideri l’esempio in figura 2.2: la proprietà di preservazio-
ne della causalità è soddisfatta, d’altronde essendo indipendenti non conta
l’ordine di esecuzione sui vari siti, tuttavia ciò non implica che si ottenga
convergenza. L’esecuzione di O1O2 restituisce "TEO", mentre l’esecuzione
di O2O1 restituisce "TET".
Vettore di stato Al fine di soddisfare la proprietà di preservazione cau-
sale (si veda definizione 2.3.3), in quasi tutti i sistemi OT si ricorre a una
struttura dati che permette di rappresentare le relazioni causali che inter-
corrono tra le operazioni del sistema. Si consideri un sistema composto da N
siti (per ipotesi N è costante, anche se è possibile generalizzare tale ipotesi),
ognuno identificato da un numero intero compreso tra 0 e N-1. Lo stato di
ciascun sito j è un vettore sj di lunghezza N, dove ogni i-esimo elemento
rappresenta il numero di operazioni del sito i eseguite sul sito j. Una strut-
tura dati di questo tipo è chiamata vettore di stato (basata su algoritmi di
timestamp per sistemi distribuiti [20, 10], introdotta nei sistemi OT [8] e
specificata più in dettaglio negli anni successivi [32, 33]).
18

27. Sito 1 Sito 2
O2 = Del(2)
TESTO
TETO
O1 = Del(3)
TESO
TEO
TESTO
TET
O2 = Del(2) O1 = Del(3)
Figura 2.2: Operazioni indipendenti
Definizione 2.3.5 (Vettore di stato). Dato un sistema composto da N siti,
ogni sito mantiene un vettore con N componenti, ciascuna per sito. Si indica
con SVk il vettore di stato sul sito k, costruito come segue:
• SVk[i] := 0 per ogni i ∈ {0, ..., N − 1} al momento iniziale
• SVk[j] := SVk[j] + 1 dopo l’esecuzione di un’operazione generata dal
sito j
Dati due vettori SVk e SVh, associati ai siti k e h, si ha:
• SVk = SVh se ogni componente di SVk è uguale al corrispondente di
SVh
• SVk < SVh se ogni componente di SVk è minore o uguale al corrispon-
dente di SVh e almeno un componente di SVk è strettamente minore
del corrispondente di SVh
• SVk > SVh se almeno un componente di SVk è maggiore del corrispon-
dente di SVh
Quando un’operazione locale Oa viene generata sul sito k, essa viene
eseguita immediatamente. Si associa a Oa un vettore di stato uguale al
vettore di stato corrente del sito: SVOa = SVk. Successivamente l’operazione
viene trasmessa agli altri siti remoti.
Quando un sito h riceve un’operazione remota Oa, generata dal sito k e
associata al vettore SVOa , essa può essere eseguita solo se valgono le seguenti
condizioni:
1. SVOa [k] = SVh[k] + 1
2. SVOa [i] ≤ SVh[i], per ogni i ∈ 0, 1, ..., N − 1 con i = k
19

28. La prima condizione stabilisce che il sito h non deve aver perso operazioni
precedenti generate dal sito k. La seconda, invece, che tutte le operazioni
generate dagli altri siti, ed eseguite sul sito k prima della generazione di Oa,
sono state eseguite sul sito h. Queste due condizioni, se entrambe valide,
assicurano che tutte le operazioni che precedono causalmente Oa sono state
eseguite, quindi garantiscono il mantenimento dell’ordine causale richiesto
dalla proprietà di preservazione causale (si veda definizione 2.3.3).
Sito 2 Sito 3
O2
Sito 1
O1
O3
O2
O3
O1 O2
O3
O1
0,1,01,0,0
0,1,01,1,0
1,2,0
1,1,0
1,2,0
1,2,0
1,1,0
Confronto [1,2,0] e [0,1,0]:
manca un op da O2.
O3 va in coda
Figura 2.3: Utilizzo del vettore di stato
In figura 2.3 si può vedere un esempio di come funzioni il vettore di
stato, in un sistema composto da tre siti. Tutte le operazioni mantengono
il proprio ordine causale e vengono eseguite immediatamente a eccezione di
O3 sul sito 2: al momento della ricezione SV del sito 2 è [0,1,0] mentre SV
dell’operazione O3 è [1,2,0]. Dal confronto tra i due vettori emerge che non è
soddisfatta la seconda delle due condizioni richieste, difatti l’operazione O3
dipende causalmente dall’operazione O1 che non è ancora stata eseguita. È
necessario quindi prevedere una struttura dove salvare l’operazione nel caso
in cui non possa essere eseguita immediatamente (ad esempio una coda).
Dopo la ricezione ed esecuzione di O1 è possibile recuperare l’operazione
O3 e finalmente eseguirla.
Il vettore di stato per mantenere l’ordinamento causale delle operazioni
viene utilizzato in diversi algoritmi della famiglia OT oltre al dOPT (lo si
trova ad esempio in adOPTed [25], GOT [34], SOCT2 [31], GOTO [9]).
20

29. 2.3.2 Modello CCI
Il secondo modello è il modello CCI (Causality Convergence Intention) in-
trodotto da C. Sun et al. [32, 33] nel 1996; esso estende il modello CC con
l’aggiunta della proprietà di preservazione dell’intento (intention preserva-
tion), basata sul concetto di intento di un’operazione visto in precedenza.
Definizione 2.3.6 (Preservazione dell’intento). Per ogni coppia di opera-
zioni Oa e Ob, se Oa||Ob, l’esecuzione di Oa e Ob in qualsiasi ordine su
ciascun sito preserva l’intento di entrambe le operazioni.
In sostanza questa proprietà assicura che l’esecuzione di un’operazione
su un sito remoto ottiene lo stesso effetto dell’esecuzione sul sito locale nel
momento in cui è stata generata. E inoltre che gli effetti dell’esecuzione di
operazioni indipendenti non interferiscono tra di loro.
Le due proprietà del modello CC, insieme a quella appena mostrata,
costituiscono la base del modello CCI. È inoltre possibile dimostrare [33]
che le tre proprietà sono indipendenti tra di loro: ciò vuol dire che anche
soddisfando due qualsiasi di esse, non è garantito che anche la terza sia
automaticamente soddisfatta.
2.4 Funzioni di trasformazione
La correttezza di un sistema OT, come visto in precedenza, dipende dal
soddisfacimento delle proprietà alla base del modello. La soluzione più sem-
plice che permette di soddisfare tali proprietà consisterebbe nel bloccare
l’esecuzione delle operazioni locali, prevedendo un meccanismo di ordina-
mento globale. In questo modo le operazioni verrebbero anzitutto ordinate
e successivamente eseguite nello stesso ordine su tutti i siti. Una soluzione
del genere, tuttavia, porterebbe notevoli svantaggi: intanto la perdita di re-
sponsività, in quanto le operazioni verrebbero eseguite con un certo ritardo
dovendo attendere l’ordinamento. Oltre a ciò, l’interfaccia utente dovrebbe
rimanere bloccata fintanto che viene effettuato l’ordinamento ed eseguita
l’operazione locale.
Una soluzione migliore consiste nell’approccio basato sulla trasformazio-
ne delle operazioni, da cui il nome Operational Transformation: le opera-
zioni ricevute vengono trasformate rispetto alle operazioni locali concorrenti
e quindi eseguite. Questa trasformazione viene effettuata utilizzando una
funzione di trasformazione, indicata con T: essa riceve come parametri due
operazioni concorrenti o1 e o2 definite a partire dallo stesso stato e resti-
tuisce o1 che è equivalente a o1, ma è definita su uno stato dove o2 è stata
applicata. Considerate quindi due operazioni o1 e o2 generate su due siti
diversi, invece di eseguire o1 ◦ o2 su un sito e o2 ◦ o1 sul secondo, si eseguono
rispettivamente o1 ◦ o2 e o1 ◦ o2, dove o1 e o2 sono le operazioni ottenute in
modo che l’effetto di entrambe le esecuzioni sia lo stesso.
21

30. 2.4.1 Trasformazione inclusiva ed esclusiva
Fino al 1998 si tratta la trasformazione di operazioni riferendosi a una gene-
rica funzione di trasformazione. Sun et al. [34] introducono una distinzione
tra due tipologie di funzioni di trasformazione:
• trasformazione inclusiva (Inclusion Transformation): indicata come
IT(Oa, Ob), trasforma un’operazione Oa rispetto a un’operazione Ob
in maniera da includere l’effetto di Ob in Oa
• trasformazione esclusiva (Exclusion Transformation): indicata come
ET(Oa, Ob), trasforma un’operazione Oa rispetto a un’operazione Ob
in maniera da escludere l’effetto di Ob
Per capire meglio cosa intende con queste due tipologie di trasformazione
è necessario introdurre il concetto di contesto. Concettualmente un’opera-
zione O è associata a un determinato contesto, indicato con CTO, costituito
dalla lista delle operazioni che vanno eseguite per portare il documento dal-
lo stato iniziale fino allo stato da cui O è stata generata. Esistono due
relazioni fondamentali riguardanti il contesto di una coppia di operazioni:
l’equivalenza e la precedenza di contesto [34].
Definizione 2.4.1 (Equivalenza di contesto " "). Date due operazioni Oa
e Ob associate ai rispettivi contesti CTOa e CTOb
, si ha che Oa e Ob sono
contestualmente equivalenti (si indica Oa Ob) se e solo se CTOa = CTOb
.
Definizione 2.4.2 (Precedenza di contesto "→"). Date due operazioni Oa
e Ob associate ai rispettivi contesti CTOa e CTOb
, si ha che Oa precede
contestualmente Ob (si indica Oa → Ob) se e solo se CTOb
= CTOa + [Oa]
(la concatenazione di CTOa e Oa).
Si consideri la trasformazione inclusiva IT(Oa, Ob) = Oa. La precondi-
zione alla base è che Oa Ob (cioè entrambe generate a partire dallo stesso
stato). La condizione che si verifica dopo la trasformazione è Ob → Oa, dove
l’effetto di esecuzione di Oa, nel proprio contesto CTOa
(che include Ob), è
lo stesso dell’esecuzione di Oa, nel proprio contesto CTOa (che non include
Ob). Eseguire Oa, su una copia dove non è stata applicata Ob, è equivalente
a eseguire Oa, su una copia dove è stata applicata Ob. In questo senso nella
trasformazione è stato incluso l’effetto di Ob.
Si consideri ora la trasformazione esclusiva ET(Ob, Oa) = Ob. La precon-
dizione alla base è che Oa → Ob (quindi Ob è stata applicata sullo stato dove
era già stata applicata Oa). La condizione che si verifica dopo la trasforma-
zione è Oa Ob. Applicare la trasformazione a una sequenza di operazioni
Oa, Ob equivale a ottenere una operazione Ob generata dallo stato iniziale
del documento, prima dell’applicazione di Oa. In questo senso nella trasfor-
mazione è stato escluso l’effetto di Oa (si veda esempio in figura 2.4).
22

31. Sito 1
TEST
Oa = Del (3)
TES
TESTO
Ob = Ins (3, "O")
Ob' = ET (Ob,Oa)
= Ins (4, "O")
TESO
Figura 2.4: Trasformazione ET
Le funzioni di trasformazione di alcuni algoritmi OT (specie i meno re-
centi) assumono nomi diversi a seconda del sistema OT (ad esempio Trans-
pose forward e Transpose backward [37]), inoltre è possibile trovare algo-
ritmi che utilizzano una funzione di trasformazione che include l’effetto di
entrambe.
2.4.2 Proprietà di trasformazione
Per garantire la correttezza di un sistema OT è necessario soddisfare le
proprietà alla base del modello di consistenza a cui si fa riferimento. Come
è possibile verificare che una determinata funzione di trasformazione soddisfi
tali proprietà e quindi sia a tutti gli effetti corretta? Sono state introdotte in
letteratura determinate condizioni che una funzione di trasformazione deve
soddisfare, se si verificano particolari precondizioni nel sistema: esse sono
dette proprietà di trasformazione. Il soddisfacimento di tali proprietà, da
parte di una funzione di trasformazione, assicura il rispetto delle proprietà
del modello di riferimento [31, 9].
Esistono due modi per garantire la correttezza del sistema: creare una
funzione di trasformazione adeguata che rispetti tali proprietà, nel caso si
verifichino queste precondizioni, oppure eliminare a priori il verificarsi del-
le precondizioni sfruttando un opportuno algoritmo di controllo (come ad
esempio avviene negli algoritmi client/server Jupiter [23], SOCT3 e 4 [37],
SCOP [29], COT [35], TIPS [27], Google OT [39]).
Alcune proprietà riguardano il mantenimento della consistenza (indicate
a volte col nome di TP1 e TP2 [25, 9, 29], a volte con C1 e C2 [37], a volte
con CP1 e CP2 [35]) altre il group undo, cioè la possibilità di annullare
l’ultima operazione locale eseguita all’interno di un contesto collaborativo
in tempo reale (sono le proprietà IP: Inverse Property 1,2,3).
23

32. Mantenimento della consistenza
Definizione 2.4.3 (Proprietà CP1/TP1). Data una coppia di operazioni
concorrenti Oa e Ob, generate a partire dallo stesso stato, una funzione di
trasformazione IT verifica la proprietà TP1/CP1 se e solo se:
Oa ◦ IT(Ob, Oa) ≡ Ob ◦ IT(Oa, Ob)
dove ≡ rappresenta l’equivalenza degli stati ottenuti dopo aver applicato
entrambe le sequenze a partire dallo stesso stato. Indicando con Oa =
IT(Oa, Ob) e Ob = IT(Ob, Oa) si può scrivere in maniera più compatta:
Oa ◦ Ob ≡ Ob ◦ Oa
La precondizione alla base della proprietà CP1/TP1 è che il sistema OT
ammetta l’esecuzione dello stesso gruppo di operazioni concorrenti in ordini
diversi.
Definizione 2.4.4 (Proprietà CP2/TP2). Date tre operazioni concorrenti
Oa, Ob e Oc, generate a partire dallo stesso stato, una funzione di trasfor-
mazione IT verifica la proprietà TP2/CP2 se e solo se:
IT(Oc, Oa ◦ IT(Ob, Oa)) ≡ IT(Oc, Ob ◦ IT(Oa, Ob))
La precondizione alla base della proprietà CP2/TP2 è che il sistema
OT ammetta la trasformazione di un’operazione rispetto lo stesso gruppo
di operazioni concorrenti in ordini diversi.
Ressel et al. hanno dimostrato [25] come il soddisfacimento di entrambe
le proprietà TP1 e TP2 sia sufficiente a garantire la convergenza delle copie e
il mantenimento dell’ordine causale delle operazioni. Il problema di estrema
importanza è che la proprietà CP2/TP2 è decisamente difficile da dimostrare
[37]. Molte funzioni di trasformazione, proposte nel corso dei vari modelli
OT, sono state introdotte con l’ipotesi che soddisfacessero tale proprietà
(senza un’effettiva dimostrazione), salvo poi scoprire successivamente che
esistevano esempi per cui la proprietà non veniva invece soddisfatta [13, 22].
Lo scenario di riferimento nel quale tipicamente non viene soddisfatta la
proprietà CP2/TP2 è definito TP2 puzzle [2, 21]: si tratta dell’esecuzione
concorrente di tre operazioni: due di inserimento e una di rimozione (si veda
figura 2.5).
In questo caso, si vede come un ordine diverso di trasformazione rispetto
un gruppo di operazioni concorrenti genera risultati finali non convergenti:
sul sito 2 O1 viene trasformata rispetto a O2 e O3, mentre sul sito 3 rispetto
a O3 e O2. Il risultato che ci si aspetta vedendo le tre operazioni è l’elimina-
zione della lettera "S" e l’inserimento delle lettere "U" e "T" in questo ordine
dopo la prima "A", quindi ciò che avviene sul sito 2. Il problema nasce dal
fatto che cambiando ordine di trasformazione si verifica un conflitto (sul si-
to 3 O1 = Ins(2, ”U”) e O2 = Ins(2, ”T”)): la trasformazione dipende da
24

33. Sito 2 Sito 3
O3 = Del (2)
CASA
CAA
O2 = Ins (3, "T")
CASTA
CATA
CASA
CATA
CAUTA
O2' = T(O2,O3) =
Ins (2, "T")
T(T(O1,O3),O2') =
Ins (3, "U")T(T(O1,O2),O3') =
Ins (2, "U")
Sito 1
O1 = Ins (2, "U")
CASA
O3' = T(O3,O2) =
Del (2)
CATUA
Figura 2.5: TP2 puzzle
come l’algoritmo gestisce un inserimento nella stessa posizione. Alcuni al-
goritmi infatti utilizzano l’identificativo del sito come priorità, quindi in tal
caso O2 avrebbe priorità più alta di O1 e quindi O1 verrebbe trasformata
in Ins(3, ”U”) producendo un risultato non corretto.
Inversione di un’operazione
Definizione 2.4.5 (Proprietà IP1). Dato un documento con stato S, un’o-
perazione O e la sua inversa O deve valere:
S ◦ O ◦ O = S
cioè la sequenza O ◦ O è equivalente all’operazione identità in relazione
all’effetto che ha sullo stato del documento
La precondizione alla base della proprietà IP1 è che il sistema OT utilizzi
operazioni inverse per implementare il meccanismo di undo.
Definizione 2.4.6 (Proprietà IP2). Dato un’operazione O e una coppia di
operazioni Ox e Ox, con O e Ox generate a partire dallo stesso stato, deve
valere:
IT(IT(O,Ox),Ox) = IT(O,I) = O
cioè il risultato della trasformazione di O rispetto a Ox e Ox in sequenza
deve essere uguale a O.
La precondizione alla base della proprietà IP2 è che il sistema OT per-
metta la trasformazione di un’operazione rispetto a una coppia di operazioni
di tipo do e undo, una per volta.
25

34. Definizione 2.4.7 (Proprietà IP3). Data una coppia di operazioni Oa e Ob
generate a partire dallo stesso stato, se Oa := IT(Oa, Ob), Ob := IT(Ob, Oa)
e Oa := IT(Oa, Ob) deve valere:
Oa = Oa
cioè la trasformata dell’operazione inversa deve essere uguale all’inverso
dell’operazione trasformata.
La precondizione alla base della proprietà IP3 è che il sistema OT per-
metta la trasformazione di un’operazione inversa rispetto a un’altra opera-
zione concorrente e definita sullo stesso stato dell’operazione originale.
2.4.3 Concorrenza parziale
È fondamentale notare come finora, nel trattare il concetto di funzione di
trasformazione, ci sia sempre riferiti a operazioni definite a partire dallo
stesso stato: affinché una trasformazione sia corretta è infatti necessaria la
validità di tale condizione. Se si tenta di trasformare operazioni generate a
partire da stati diversi non è assicurata la preservazione dell’intento [37].
Sito 1 Sito 2
O1 = Del (0) O3 = Del (2)
CASA
CAA
O2 = Ins (2, "M")
ASA
ASMA
CASA
AA
AAM
AMA
T(O1,O3) = Del (0)
T(O2,O3) = Ins (2, "M")
T(T(O3,O1),O2) = Del (1)
Figura 2.6: Scenario con concorrenza parziale
Un esempio di questa problematica è dato dallo scenario chiamato con-
correnza parziale che si verifica quando un’operazione è concorrente a una
sequenza di operazioni. Nella figura 2.6 è mostrato lo scenario: un sistema
con un documento condiviso ("CASA") tra due siti, il primo genera le ope-
razioni O1=Del(0) e O2=Ins(2,"M"), mentre il secondo genera O3=Del(2).
Quando il sito 1 riceve O3, la trasforma rispetto alle operazioni precedenti,
ottiene O3’=Del(1) e la esegue ottenendo come stato finale "AMA". Quando
26

35. il sito 2 riceve O1, la trasforma rispetto O3: O1 non viene modificata in
quanto non in conflitto con O3 e viene applicata ottenendo "AA". A questo
punto viene ricevuta O2, che viene anch’essa trasformata con O3 e rimane
invariata (inserimento ed eliminazione nella stessa posizione non rappresen-
tano un conflitto). Il risultato finale sul sito 2 è "AAM": esso differisce dal
risultato sul sito 1. Il problema di fondo nasce nel momento in cui il sito 2
riceve l’operazione O2; O2 viene trasformata nei confronti delle operazioni
a essa indipendenti, quindi O3, tuttavia O2 e O3 non sono state generate a
partire dallo stesso stato. Infatti O2 è stata generata tenendo conto dell’ef-
fetto di O1, quindi la posizione riferita da O2 e la posizione riferita da O3
non possono essere messe in relazione, poiché riferiscono stati diversi.
Questo scenario venne scoperto per la prima volta dopo la pubblicazione
dell’algoritmo dOPT e inizialmente fu chiamato dOPT Puzzle proprio perché
dimostrava la non correttezza della funzione di trasformazione proposta in
dOPT (si faccia riferimento alla sezione 2.5.1).
2.5 Algoritmi OT
Verranno ora presi in esame alcuni dei principali algoritmi OT, introdotti
nel corso degli anni, mettendo in luce quali meccanismi siano stati proposti
al fine di soddisfare le proprietà dei modelli visti in precedenza. L’intento
di questo capitolo è fornire una panoramica globale sulle tecniche utilizzate
nei vari sistemi e sull’effettiva correttezza delle funzioni di trasformazione
proposte, al fine di scegliere quali siano gli algoritmi più affidabili per la
progettazione di un sistema collaborativo simultaneo. Non si scende nel
dettaglio né degli algoritmi, né dell’effettiva implementazione: per quello si
rimanda il lettore alla documentazione di riferimento.
Sono stati considerati algoritmi basati sia su architetture distribuite
(dOPT e adOPTed [8, 25], SOCT2 [31], GOT e GOTO [34, 9], TIBOT
e TIBOT 2.0 [21, 38]), sia su un’architettura client-server (Jupiter [23],
SOCT3 e 4 [37], SCOP [29], COT [35], TIPS [27], Google OT [39]).
2.5.1 dOPT e adOPTed
Il primo algoritmo per la gestione della concorrenza, proposto da C. A. Ellis
e S. J. Gibbs [8] nel 1989, utilizzabile in ambito collaborativo e basato sulla
nozione di Operational Transformation, è l’algoritmo dOPT. È implemen-
tato in quello che fu uno dei primi editor collaborativi testuali, il GROVE
(Group Online Viewing Editor). Il sistema di riferimento è completamente
distribuito: molteplici utenti lavorano su siti interconnessi tramite una rete
ipotizzata affidabile (quindi priva di errori o pacchetti duplicati) e generano
operazioni (inserimento o rimozione di un carattere) su una replica locale
del documento condiviso. Ogni sito mantiene un buffer (chiamato log) delle
27

36. operazioni locali eseguite nel loro ordine di esecuzione e un vettore di stato
(così come definito in 2.3.5) per mantenere l’ordine causale delle operazioni.
Il funzionamento dell’algoritmo può essere schematizzato a grandi linee
come segue:
• Quando un’operazione è generata su un sito, viene eseguita e propa-
gata agli altri utenti assieme al vettore di stato corrente
• Quando un’operazione inviata da un sito s1 viene ricevuta da un sito
s2, viene esaminato il vettore di stato e si valuta l’ordine di esecuzione:
Se s1 ha eseguito altre operazioni non ancora eseguite da s2,
l’operazione è messa in coda
Se viceversa s2 ha eseguito operazioni non ancora eseguite da
s1, l’operazione ricevuta viene trasformata nei confronti delle nuove
operazioni e successivamente viene eseguita
Se s2 non ha eseguito operazioni non ancora eseguite da s1, l’ope-
razione viene eseguita direttamente
La funzione di trasformazione è di tipo inclusivo ed è costituita da una
matrice di trasformazione T. La trasformazione tiene conto del tipo di ope-
razione (insert o delete) e di un parametro che rappresenta la priorità del-
l’operazione (tale parametro dipende dal sito che ha generato l’operazione,
nell’esempio più semplice si utilizza l’identificativo numerico del sito). Al
momento in cui fu proposto il sistema dOPT ancora non erano state definite
formalmente né la proprietà CP1/TP1 né la CP2/TP2. Si richiede che la
funzione soddisfi una proprietà simile alla CP1/TP1, ma senza la condizio-
ne che le due operazioni da trasformare siano generate a partire dallo stesso
stato.
Nel corso degli studi successivi è stato dimostrato [25, 23, 34, 24] che l’al-
goritmo dOPT non funziona correttamente nello scenario chiamato dOPT
puzzle; sostanzialmente esso rappresenta uno dei primi esempi di concorren-
za parziale (si veda capitolo 2.4.3). In tale caso la convergenza non viene
assicurata, pertanto l’algoritmo non può considerarsi corretto.
adOPTed
Un’evoluzione dell’algoritmo dOPT, che risolva il dOPT puzzle, venne pro-
posta da Ressel et al. [25] nel 1996. Essa condivide con dOPT la struttura
distribuita, il modello di riferimento (modello CC visto in 2.3.1) e l’utilizzo
dei vettori di stato per mantenere l’ordinamento causale delle operazioni. Le
novità risiedono nella sostituzione del parametro di priorità con il semplice
identificativo del sito e nell’introduzione di un buffer multidimensionale, su
ciascun sito, per salvare i differenti percorsi (sequenze di operazioni) che
portano dallo stato iniziale del documento allo stato attuale. Oltre alle
28

37. operazioni originali vengono salvati nel buffer i risultati delle trasformazio-
ni, che potranno essere riutilizzati nel caso di trasformazioni successive. In
questo modo, ogni volta che arriva un’operazione, viene scelto il percorso
appropriato lungo il quale effettuare la sequenza di trasformazioni. La fun-
zione di trasformazione basa la sua correttezza sulle proprietà TP1/CP1
e TP2/CP2; è stato tuttavia dimostrato [24, 13] che tale funzione di tra-
sformazione non è corretta in quanto soddisfa la proprietà TP1/CP1, ma
non quella TP2/CP2. Oltre a ciò non è mai stato provato che venga sod-
disfatta la proprietà di preservazione dell’intento [19], sebbene il modello di
riferimento non lo richieda.
2.5.2 Jupiter
Gli algoritmi visti in precedenza si basano entrambi su un approccio di-
stribuito: ogni sito ha la necessità di conoscere tutti gli altri partecipanti
del sistema e di entrare direttamente in comunicazione con ciascuno di essi.
Un approccio alternativo che semplifica l’algoritmo di controllo consiste nel-
lo sfruttare un server centralizzato che gestisce le comunicazioni tra i vari
client: è il caso dell’algoritmo Jupiter, presentato da Nichols et al. [23] nel
1995. L’algoritmo prende il nome dall’omonimo sistema collaborativo, pro-
gettato dalla Xerox PARC, basato sulla condivisione di widget grafici che
contengono documenti o elementi multimediali.
Come nel caso distribuito, ciascun client effettua operazioni locali su
una replica del documento che viene mantenuta in sincronizzazione con il
server. La novità rispetto a un tradizionale sistema client/server, in cui il
server mantiene l’intero onere della sincronizzazione, è che il client presenta
anch’esso una parte di logica, processando i messaggi ricevuti dal server.
L’analogo della matrice di trasformazione T vista in dOPT è una fun-
zione di trasformazione chiamata xform. Dati un messaggio locale c e un
messaggio remoto s, essa viene indicata come xform(c, s) = (c , s ) (con
c ◦ s = s ◦ c ): deve quindi soddisfare la proprietà CP1/TP1 (si veda la
sezione 2.4.2).
L’algoritmo di controllo, utilizzato dal protocollo di sincronizzazione in
Jupiter, si basa su uno spazio di stato: una struttura bidimensionale che
mantiene il percorso dallo stato iniziale del documento allo stato corrente.
Ogni stato è rappresentato dal numero di messaggi processati dal client e dal
server, in tal modo ogni coppia client-server può mantenere un’informazione
sullo stato in cui si trova la controparte, in relazione al proprio. Ad esempio,
se il client si trova nello stato (2,1) vuol dire che ha generato e processato
2 messaggi localmente, mentre ha ricevuto e processato un messaggio dal
server.
29

38. Divergenza per un’operazione Se il client e il server processano i mes-
saggi nello stesso ordine prendono lo stesso percorso, altrimenti i percorsi
divergono (si veda figura 2.7).
1,0 0,1
S1
0,0
C1
Operazione
lato client
Operazione
lato server
Figura 2.7: Divergenza tra client e server in Jupiter
Quando il client e il server si trovano in due stati differenti, entra in gio-
co la funzione xform vista in precedenza. Lato client, dopo aver processato
il messaggio c1 generato localmente, viene ricevuto dal server il messaggio
s1 generato da un’altro client. A questo punto, partendo dalla coppia (c1,
s1) si produce la coppia (c1’, s1’) utilizzando la xform. È quindi possibile
processare s1’ per arrivare allo stato finale del documento (si veda spazio di
stato n.1 in figura 2.8). Analogamente lato server, una volta ricevuto il mes-
saggio c1 dal client, viene applicata la xform e processato c1’ raggiungendo
la convergenza (lo spazio di stato finale sul client è il n.2 in figura 2.8).
(2)
1,0 0,1
S1
0,0
C1
Operazione
lato client
Operazione
lato server
1,1
S1'
1,0 0,1
S1
0,0
C1
1,1
S1' C1'
(1)
Operazione
trasformata
Figura 2.8: Trasformazione e convergenza in Jupiter
Divergenza per più operazioni da un lato Nei casi reali la complessità
dello schema aumenta, ad esempio il server potrebbe divergere dal client per
più di un’operazione (si veda figura 2.9).
30

39. 1,0 0,1
S1
0,0
C1
Operazione
lato client
Operazione
lato server
0,2
S2
Figura 2.9: Divergenza per più operazioni da un lato in Jupiter
Lato client, dopo aver processato il messaggio c1, viene ricevuto il mes-
saggio s1. Sfruttando la coppia (c1,s1) si ottiene il messaggio trasformato
s1’ che viene processato (si veda immagine n.1 in figura 2.10). A questo
punto viene ricevuto il messaggio s2. Come è possibile gestire il messaggio
s2, dal momento che proviene da uno stato non noto al client? Non si può
applicare la funzione xform(c1, s2) poiché è applicabile solo su coppie di
messaggi che hanno origine dallo stesso stato.
(2)
1,0 0,1
S1
0,0
C1
Operazione
lato client
Operazione
lato server
1,1
S1'
1,0
S1
0,0
C1
S1'
(1)
Operazione
trasformata
0,2
S2
C1'
0,1
0,2
S2
C1'
1,2
1,1
S2' C1''
Figura 2.10: Risoluzione della divergenza per più operazioni da un lato in
Jupiter
Quando il client aveva ricevuto s1, aveva applicato xform(c1, s1) otte-
nendo la coppia s1’ e c1’. Il messaggio s1’ era stato processato, mentre
c1’ era stato scartato. Tuttavia c1’ rappresenta un messaggio fittizio che
31

40. collega lo stato in cui si trova il client dopo s1’ (1,1) e lo stato in cui si
trovava il server dopo s1 (0,1). Poiché c1’ proviene dallo stesso stato di
s2, si è trovato ciò che mancava per trasformare s2: è sufficiente eseguire
xform(c1 , s2) ottenendo il messaggio trasformato s2’ (si veda immagine
n.2 in figura 2.10).
Divergenza per più operazioni Nel caso generico in cui il client e server
divergano entrambi per più operazioni (si veda immagine n.1 in figura 2.11),
la soluzione è analoga a quanto appena visto.
(2)
0,1
S1
0,0
C1
Operazione
lato client
Operazione
lato server
(1)
Operazione
trasformata
0,2
S2
2,0
C2
1,0 0,1
S1
0,0
C1
1,1
S1'
0,2
S2C1'
2,0
C2
1,0
2,0
C2'S1''
0,1
S1
0,0
C1
1,1 0,2
S2C1'
2,0
C2
1,0
2,1
C2'S1''
1,2
C1''
2,2
C2''
S2'
S2''
(3)
0,1
S1
0,0
C1
1,1 0,2
S2C1'
2,0
C2
1,0
2,1
C2'S1''
1,2
C1''
2,2
C2''
S2'
S2''
(4)
S1'S1'
Figura 2.11: Divergenza per più operazioni in Jupiter (caso complesso)
Lato client, dopo aver processato c1 e c2 viene ricevuto dal server il
messaggio s1. Si utilizza la funzione xform applicata alla coppia (c1,s1)
ottenendo la coppia (c1’,s1’). Il messaggio s1’ questa volta non viene pro-
cessato, ma utilizzato invece per la trasformazione successiva: la coppia (c2,
s1’) va in ingresso alla xform, ottenendo la coppia (s1”,c2’). A questo punto
il client può processare s1” (si veda immagine n.2 in figura 2.11).
32

41. Alla fine di ogni trasformazione il client salva la versione trasformata dei
propri messaggi (in questo caso c1’ e c2’). Tali messaggi rappresentano ciò
che viene definito ponte (bridge): si tratta di un percorso che rappresenta,
per il client, il collegamento tra l’ultimo stato noto del server (nell’esempio è
(0,1)) e il proprio stato attuale (nell’esempio è (2,1)). Mantenendo il ponte è
possibile trasformare un eventuale messaggio successivo in maniera semplice.
Quando il client, infatti, riceve il messaggio s2, è sufficiente che applichi la
funzione xform prima alla coppia (c1’,s2) e successivamente a (c2’,s2’). In
questo modo ottiene s2” da processare e i due messaggi c1” e c2”, ottenuti
durante le trasformazioni, che rappresentano il nuovo ponte da memorizzare
(si veda immagine n.3 in figura 2.11).
Analogamente avviene lato server; alla fine del processo si ottiene la con-
vergenza (lo spazio di stato finale sul client è il n.4 in figura 2.11).
Se non si mantenesse un ponte, sarebbe necessario ricostruire il percorso
delle trasformazioni ogni volta che si riceve un’operazione generata da uno
stato non noto. Considerando l’esempio precedente (immagine n.1 in figura
2.11): quando il client riceve s2 dovrebbe ricostruire tutte le trasformazioni
intermedie a partire dall’ultimo stato convergente (indicate in grigio nel-
l’immagine n.2). Oltre a ciò bisognerebbe mantenere una copia di tutte le
operazioni ricevute oltre a quelle locali.
Così come ogni client mantiene uno spazio di stato, anche il server deve
quindi mantenere una copia dello spazio di stato, per ciascun client con cui è
in comunicazione, in cui poter salvare il ponte necessario alle trasformazioni
successive. Nel caso di N client, dunque, ciascun client mantiene il proprio
spazio bidimensionale, mentre il server mantiene N spazi bidimensionali (in
adOPTed ciascun client mantiene uno stato N-dimensionale).
Dal momento che il server contribuisce a mantenere un ordinamento
globale delle operazioni, la precondizione della proprietà CP2/TP2 viene
a mancare [41], quindi la xform necessita di soddisfare solo la proprietà
CP1/TP1. L’implementazione dell’algoritmo di controllo è sicuramente me-
no complessa rispetto al caso di un’architettura distribuita (come in dOPT e
adOPTed). La presenza del server centrale, da un lato potrebbe rappresen-
tare il collo di bottiglia del sistema, dall’altro però costituisce un punto di
riferimento nel caso di guasti (se una copia su un client dovesse corrompersi
si può richiedere la copia del documento presente sul server e riprendere le
modifiche da quel punto).
33

42. 2.5.3 GOT e GOTO
Un approccio diverso alla teoria OT vista finora viene apportato dall’algo-
ritmo GOT (Generic Operational Transformation), proposto da Sun et al.
[34] nel 1998. Già nel 1996 [32, 33] gli stessi autori pongono le basi teori-
che per un nuovo modello di consistenza, il modello CCI (si veda la sezione
2.3.2), introducendo il concetto di preservazione dell’intento. Sempre nello
stesso lavoro vengono descritti i meccanismi per il soddisfacimento delle tre
proprietà: per il mantenimento dell’ordine causale si sfruttano vettori di sta-
to (come già successo per dOPT e adOPTed), mentre per il mantenimento
della convergenza e dell’intento viene presentato un nuovo schema basato
sull’annullamento di operazioni già eseguite (undo).
Preservazione della convergenza La preservazione della convergenza
in GOT viene ottenuta tramite uno schema di tipo undo/do/redo basato su
un ordinamento totale delle operazioni.
Definizione 2.5.1 (Relazione di ordinamento totale). Date due operazioni
Oa e Ob generate sui siti i e j e associate rispettivamente ai vettori di stato
SVOa e SVOb
allora si ha che Oa precede totalmente Ob (o egualmente Ob
segue totalmente Oa) e si indica con Oa ⇒ Ob se e solo se:
1. Sum(SVOa ) < Sum(SVOb
) oppure
2. Sum(SVOa ) = Sum(SVOb
) e i<j
dove Sum(SV ) = N−1
i=0 SV [i]
Viene dimostrato inoltre che se Oa → Ob allora Oa ⇒ Ob.
GOT mantiene un buffer, detto History Buffer (HB), con tutte le opera-
zioni eseguite localmente e ordinate secondo l’ordinamento totale (la relazio-
ne ⇒). Al momento di eseguire una nuova operazione On (locale o remota) si
verifica se nel buffer sono presenti operazioni che seguono totalmente On. In
caso negativo l’operazione viene semplicemente eseguita, in caso affermativo
tali operazioni vengono annullate (undo), viene eseguita l’operazione ricevu-
ta (do) e in seguito si riapplicano le operazioni precedentemente annullate
(redo). Un esempio è visibile in figura 2.12. Per applicare uno schema di
questo tipo è necessario che le operazioni siano reversibili, ed è auspicabile
prevedere un meccanismo di garbage collector che si occupi della pulizia dal
buffer di operazioni obsolete.
Viene dimostrato [34] che uno schema undo/do/redo garantisce la con-
vergenza (quindi soddisfa l’omonima proprietà del modello di consistenza).
34

43. Sito 1 Sito 2 Sito 3
O1
Undo (O2)
Do (O1)
Do (O2)
O3
O2
Do (O2)
Do (O3)
Do (O2)
Undo (O2)
Do (O1)
Do (O2)
Do (O3)
Figura 2.12: Applicazione dello schema undo/do/redo
Preservazione dell’intento Lo schema di preservazione della convergen-
za e l’utilizzo di vettori di stato non assicurano il non verificarsi della vio-
lazione dell’intento, dal momento che l’intento non è correlato all’ordine
di esecuzione delle operazioni. Per ottenere la preservazione dell’intento è
necessario che un’operazione già ordinata causalmente venga trasformata
prima della sua esecuzione; in questo modo si vanno a compensare i cambia-
menti effettuati allo stato del documento da parte di altre operazioni prece-
denti. Integrando la trasformazione con lo schema proposto in precedenza
si ottiene lo schema undo/transform-do/transform-redo.
Al momento di eseguire una nuova operazione On vengono annullate tut-
te le operazioni nel HB che seguono totalmente On, in modo da ripristinare lo
stato del documento a prima della loro esecuzione (undo). Successivamente
viene trasformata On rispetto a tutte le operazioni indipendenti che la prece-
dono totalmente e viene applicata l’operazione trasformata (transform-do).
Infine si trasformano, una a una, tutte le operazioni annullate in precedenza
rispetto alla trasformata di On e si riapplicano (transform-redo). Un esem-
pio è visibile in figura 2.13.
Senza scendere troppo nel dettaglio dello schema, è interessante come
per implementare uno schema simile viene introdotto per la prima volta il
concetto di trasformazione inclusiva (IT) e trasformazione esclusiva (ET)
(già discusse nella sezione 2.4). In particolare l’utilizzo di una trasformazione
ET è necessaria per il riordino del buffer. La novità importante è che, dal
momento che lo schema visto in precedenza mantiene un ordine globale di
esecuzione e trasformazione delle operazioni, si è eliminato il verificarsi delle
35

44. Sito 1 Sito 2 Sito 3
O1
Undo (O2)
Do (O1)
T-redo (O2)
O3
O2
Do (O2)
Do (O3)
T-do (O2)
Undo (O2)
Do (O1)
T-redo (O2)
Do (O3)
Figura 2.13: Applicazione dello schema undo/transform-do/transform-redo
precondizioni alla base delle proprietà CP1/TP1 e CP2/TP2 (si veda la
sezione 2.4.2). Ciò implica che la funzione di trasformazione IT non dovrà
soddisfare tali proprietà: un notevole passo avanti nella semplificazione della
funzione di trasformazione a discapito delle performance dell’algoritmo di
controllo che richiede continui cicli di undo e redo.
GOTO
Gli stessi autori di GOT propongono nel 1998 una versione ottimizzata del-
l’algoritmo, chiamata GOTO [9]; essa è stata testata nell’editor collaborativo
CoMaya6. L’idea alla base è di implementare delle funzioni IT/ET che sod-
disfino le proprietà CP1/TP1 e CP2/TP2. Effettivamente GOTO risolve
entrambi i problemi del TP2 puzzle e della concorrenza parziale (visti in pre-
cedenza), tuttavia risulta essere un algoritmo molto costoso e decisamente
poco performante dal momento che richiede costantemente la riorganizzazio-
ne del buffer locale per integrare ogni operazione remota e mantenere l’ordi-
ne globale [2]. Più specificamente, la complessità temporale dell’algoritmo
GOTO risulta essere dell’ordine di O(n2) [21].
6
http://cooffice.ntu.edu.sg/comaya/
36

45. 2.5.4 SOCT2 e SOCT3/4
Nell’algoritmo SOCT2, introdotto da Suleiman [31] nel 1998, si riprendo-
no i concetti visti nei precedenti algoritmi trattati: l’utilizzo di vettori di
stato per il mantenimento dell’ordine causale e l’utilizzo di due funzioni di
trasformazione, una inclusiva chiamata forward transposition e una esclu-
siva chiamata backward transposition. In particolare la seconda funzione
permette la modifica dell’ordine di esecuzione di una coppia di operazioni
rispettando l’intento dell’utente.
Analogamente a GOTO e adOPTed, la funzione di trasformazione (in-
clusiva) necessita di soddisfare la proprietà CP2/TP2 che come visto in
precedenza non sempre è facile da rispettare. È stato dimostrato [24] che la
funzione di trasformazione proposta in SOCT2, basata su inserimento e ri-
mozione di un carattere in un documento testuale, non soddisfa né CP1/TP1
né CP2/TP2. Inoltre, l’algoritmo non è neppure particolarmente efficiente:
l’integrazione di un’operazione remota nel buffer, con conseguente riorga-
nizzazione del buffer (sfruttando la funzione di trasformazione ET) non è
un’operazione performante.
Gli stessi autori propongono due anni dopo due nuove versioni dell’algo-
ritmo: SOCT3 e SOCT4 [37].
SOCT3
L’algoritmo SOCT3 introduce un meccanismo centralizzato, detto sequen-
cer, che si occupa di mantenere un ordine globale di esecuzione delle ope-
razioni sfruttando sistemi di timestamp (come visto per il vettore di stato).
Il sequencer si limita a generare dei numeri di sequenza per le operazioni,
non si occupa né di effettuare trasformazioni, né di propagare le operazioni
ai vari siti. Su ciascun sito vengono sfruttate le funzioni di trasformazione
IT ed ET viste in precedenza per riordinare il buffer come già accadeva in
SOCT2. Questa soluzione sicuramente porta a risolvere il TP2 puzzle (si
veda la sezione 2.4.2) e quindi risolve il problema di soddisfare la proprietà
CP2/TP2. Ovviamente tutto ciò a discapito della scalabilità (si passa da
un’architettura distribuita a una client/server).
SOCT4
Il passo successivo per migliorare l’algoritmo è dato dalla rimozione dello
schema di undo/do/redo (quindi della funzione di trasformazione ET) ed è
quanto viene proposto dagli autori con l’algoritmo SOCT4. Al fine di ot-
tenere questo risultato vanno effettuate delle restrizioni al meccanismo di
broadcast: in pratica un sito può propagare le sue operazioni locali solo se
ha già integrato tutte le operazioni remote che precedono totalmente le ope-
razioni locali (tale meccanismo è chiamato deferred broadcasting). Un primo
vantaggio sicuramente risiede nella semplicità dell’implementazione: non è
37

46. più necessario modificare l’ordine di esecuzione annullando e riapplicando
operazioni, inoltre ciascun sito deve mantenere solo un buffer delle opera-
zioni locali (senza necessità di mantenere tutto lo storico delle operazioni
applicate). Un altro vantaggio è che la proprietà CP2/TP2 non va soddi-
sfatta (come accade già per SOCT3) e che viene risolto il problema della
concorrenza parziale, tuttavia ciò complica la collaborazione nel caso di una
rete ad alta latenza (l’attesa delle operazioni remote da integrare rallenta
tutto il sistema). L’ultimo vantaggio da considerare è la sostituzione della
struttura a vettori di stato, rimpiazzata da semplici numeri scalari identifi-
cativi di un’operazione (dal momento che l’ordine è gestito dal server, non
è più necessario che ogni sito conosca quante operazioni generate dagli altri
siti sono state eseguite localmente).
2.5.5 SCOP
Un approccio molto simile a quello visto in SOCT4 si trova nell’algoritmo
SCOP (Symmetric Contextually serialized Operation Propagation), propo-
sto da Shen et al. [29] nel 2002 all’interno di un progetto per un sistema
di gestione di notifiche. Tale sistema utilizza un server centrale, chiama-
to notifier, che ordina le operazioni e si occupa di trasformarle. Ogni sito
mantiene due buffer: uno per le operazioni da inviare al notifier e un altro
per le operazioni ricevute. Il protocollo che gestisce lo scambio dei messaggi
con il notifier è detto SCOP, da cui deriva il nome dell’algoritmo. Inizial-
mente viene implementata una comunicazione client/server di tipo esclusivo:
un unico client per volta può comunicare col server. Il meccanismo si ba-
sa sull’utilizzo di un token, un particolare messaggio inviato dal server che
permette al solo client che lo riceve di effettuare la comunicazione; gli altri
client che hanno fatto richiesta verranno salvati in una coda. Una volta che
il client ha inviato al server l’operazione, viene rilasciato il token: in sostan-
za il client in questione perde il diritto acquisito di comunicazione e il server
procede accordando il permesso di comunicare al successivo client in coda
(se presente). Successivamente l’algoritmo viene migliorato optando per una
soluzione che permette a più siti di propagare i messaggi al server, in ma-
niera concorrente. Per quanto riguarda la trasformazione, è stato introdotto
un algoritmo che permette di trasformare simmetricamente due sequenze di
operazioni, l’algoritmo SLOT (Symmetric Linear Operation Transform): es-
so si basa su una funzione di trasformazione inclusiva simmetrica (SIT). Un
altro elemento interessante introdotto è dato da un algoritmo di compres-
sione detto CLOM (Compress a Log by Operational Merging) che si occupa
di ridurre le dimensioni dei vari buffer al fine di ottimizzare sessioni colla-
borative di lunga durata. Come in SOCT4 non viene fatto uso di vettori di
stato, non viene utilizzata la trasformazione ET e viene risolto il problema
della soddisfabilità di CP2/TP2 (mantenendo l’ordine globale garantito dal
notifier) [29, 38].
38

47. 2.5.6 TIBOT e TIBOT 2.0
Nel 2004 Li et al. [21] sono i primi a proporre un algoritmo totalmen-
te distribuito che mantiene l’ordine totale delle operazioni senza utilizzare
un server centrale, l’algoritmo TIBOT (Time Interval Based OT). Alcuni
concetti sono stati ripresi da algoritmi precedenti (l’algoritmo SLOT per
le trasformazioni e lo schema undo/transform-do/transform-redo visto in
GOT), mentre il meccanismo per l’ordinamento causale è completamente
nuovo rispetto alla tecnica dei vettori di stato.
L’idea di fondo è di generare un clock logico lineare su ciascun sito e
considerare l’intervallo di tempo tra due valori di clock (es. l’intervallo di
tempo 3 è quello che va dal valore di clock 3 al valore 4). Quando un’opera-
zione viene generata, essa viene associata all’intervallo di tempo corrente. Si
adattano successivamente le relazioni di ordine causale e totale viste in pre-
cedenza (si veda definizione 2.3.1) al concetto di intervallo di tempo (anziché
a vettori di stato). Questo nuovo approccio richiede alcune regole legate alla
propagazione e la sincronizzazione, tra cui alcune limitazioni riguardanti le
operazioni locali (non possono essere inviate agli altri siti finché non sono
state trasformate con le operazioni generate in intervalli di tempo prece-
denti) e le operazioni remote (non possono essere eseguite localmente finché
tutte le operazioni generate in intervalli di tempo precedenti non sono state
eseguite). Inoltre il vincolo più importante da considerare è che la sincro-
nizzazione con gli altri siti non è istantanea, ma avviene regolarmente alla
fine di ciascun intervallo di tempo.
Alcune considerazioni vanno fatte riguardo al tempo di risposta (il tempo
che intercorre tra la generazione di un’operazione e l’esecuzione su un sito
remoto). Anzitutto è necessaria una rete di comunicazione con minor latenza
possibile: l’esecuzione di operazioni remote viene infatti già ritardata per
motivi di ordinamento e sincronizzazione, quindi sarebbe auspicabile che
quantomeno la rete non contribuisca al ritardo. Oltre a ciò, la scelta della
grandezza degli intervalli di tempo è anch’essa fondamentale: un valore
troppo alto rallenterebbe la sincronizzazione (che viene effettuata alla fine
di ogni intervallo), d’altro canto un valore troppo basso provocherebbe un
traffico elevato sulla rete (dal momento che a ogni fase sincronizzazione tutti
i siti comunicano tra di loro).
Grazie all’ordinamento totale, TIBOT evita la precondizione alla base
di CP2/TP2 quindi non necessita il soddisfacimento di tale proprietà (come
già accade per SOCT3/4, GOT e SCOP) [41]; inoltre, esso presenta una
complessità temporale dell’ordine di O(n), risolve il TP2 puzzle ed evita
l’utilizzo della funzione di trasformazione ET [21].
39

48. TIBOT 2.0
L’algoritmo TIBOT offre i vantaggi visti in precedenza, tuttavia riprende da
GOT l’utilizzo dello schema undo/transform-do/transform-redo per mante-
nere l’ordine totale delle trasformazioni. È possibile utilizzare meccanismi
più efficienti che evitino il continuo undo e redo delle operazioni, ed è ciò
che viene proposto nel 2014 da Xu et al. [38] con TIBOT 2.0, un’evoluzione
dell’algoritmo TIBOT. Il principio e la struttura sono gli stessi, l’unico cam-
biamento è dato dall’introduzione di una trasformazione simmetrica che so-
stituisce il processo di undo e redo. Restano valide le considerazioni fatte per
TIBOT, per i dettagli dell’implementazione si rimanda alla documentazione.
2.5.7 COT
Tra i diversi sistemi OT proposti, COT (Context-based OT), introdotto da
Sun et al. [35] nel 2006, è il primo a supportare sia il mantenimento della
consistenza che il group undo. Con group undo non si intende l’undo visto in
precedenza in alcuni meccanismi di controllo, bensì la richiesta di un utente
di annullare un’operazione già eseguita, all’interno del contesto collaborati-
vo. Come già successo con GOT, GOTO, SOCT2, SOCT3 e SOCT4 anche
COT punta a definire un ordine totale tra le operazioni: in questo modo si
evita il verificarsi della precondizione della proprietà CP2/TP2, permetten-
do l’utilizzo di una funzione di trasformazione che soddisfa solo la proprietà
CP1/TP1. La novità più grande, però, arriva dall’introduzione di un’intera
teoria basata sul contesto di un’operazione, che punta a risolvere i limiti
della teoria della preservazione della causalità (si veda definizione 2.3.3).
Il primo punto messo in evidenza riguarda la validità della relazione di
ordine causale (si veda sezione 2.3.1), limitata esclusivamente alle operazioni
normali e non alle operazioni trasformate o a quelle inverse. Ciò risulta
evidente al momento di gestire operazioni inverse: esse non hanno nessi
causali con altre operazioni (un’operazione inversa non dipende da altre
operazioni precedenti). Il problema di fondo è che alcuni sistemi OT basano
l’ordine della trasformazione sulla relazione causale, ma ciò non è necessario,
due operazioni possono venire trasformate a prescindere da un ordine causale
presente o meno tra di loro. Piuttosto di considerare l’ordine causale si
considera il contesto di un’operazione.
Il contesto di un’operazione, denotato da C(O) corrisponde allo stato
del documento al momento in cui l’operazione viene generata. In un editor
collaborativo lo stato del documento (indicato con DS) in un certo istante
può essere unicamente definito dal set di operazioni eseguite fino a tale
istante (indipendentemente dall’ordine di esecuzione, se vale la proprietà di
convergenza). Inoltre la differenza tra due stati diversi può essere espressa
dalle operazioni differenti applicate su tali stati.
40

49. Definizione 2.5.2 (Contesto di un’operazione). Si definisce contesto di
un’operazione O (indicato con C(O)):
1. Per un’operazione normale, O: C(O) = DS
2. Per un’operazione inversa, O: C(O) = C(O) ∪ {O}
3. Per un’operazione trasformata, O = IT(O, Ox): C(O ) = C(O)∪{Ox}
Quindi lo stato di una normale operazione O è quello del documento
al momento della sua generazione. Lo stato di un’operazione inversa O è
quello in cui O è l’ultima operazione eseguita. Infine lo stato di un’opera-
zione trasformata è quello dell’operazione normale, al quale viene applicata
l’operazione rispetto alla quale trasformare.
Vengono successivamente introdotte sei condizioni, chiamate Context-
based Conditions (CC), che si devono verificare per l’esecuzione e trasfor-
mazione di operazioni. Particolarmente importanti sono la condizione per
l’esecuzione di un’operazione su un determinato documento (C(O) = DS) e
quella per la trasformazione IT di due operazioni (C(Oa) = C(Ob)). Come
si può vedere, è possibile trasformare due operazioni solo se il loro contesto
è lo stesso (ciò è analogo alle considerazioni fatte per le proprietà CP1/TP1
e CP2/TP2 dove si richiedeva che le operazioni fossero generate a partire
dallo stesso stato). La cosa fondamentale è che queste condizioni sono le-
gate al contesto e non genericamente allo stato, quindi valgono anche per
operazioni inverse e trasformate.
Per rappresentare il contesto di un’operazione O, utilizzando sia opera-
zioni normali che inverse, si utilizza un vettore di contesto (context vector)
indicato con CV (O).
Sfruttando le relazioni viste finora viene proposto un algoritmo che im-
plementa sia l’esecuzione di un’operazione (COT-DO) che l’annullamento
di un’operazione già eseguita (COT-UNDO). Viene specificato che tale al-
goritmo evita la necessità di soddisfare la proprietà CP2/TP2, mantenendo
un ordine globale (questa volta basato su relazioni di contesto e non causali,
come avveniva per gli altri algoritmi). Inoltre per quanto riguarda la parte
di undo e le rispettive proprietà IP1, IP2 e IP3 (si veda la sezione 2.4.2)
vengono evitate la precondizioni alla base di IP2 e IP3, rendendo quindi
non necessario il soddisfacimento di tali proprietà da parte della funzione di
trasformazione.
Uno dei problemi di questo approccio è sicuramente la quantità di me-
moria richiesta per salvare i vettori di contesto con lo storico delle operazioni
eseguite. Sicuramente si deve pensare a implementare dei meccanismi di gar-
bage collector che permettano di ridurre la dimensione dei vettori eliminando
le operazioni non più necessarie.
41