La cohérence forte présente, dans un premier temps, l’approche la plus intuitive pour une application collaborative dans le cloud.
Cherchons dans un premier temps à répliquer un processus d’édition local d’un document. Formalisons alors ce qu’on attend d’une application d’édition de document seulement local.

Nous avons un acteur qui va réaliser deux types d’actions différentes, la lecture ou l’écriture d’un document. Ces opérations sont des opérations atomiques du point de vue de l’utilisateur et il ne peut les exécuter que l’une après l’autre. Dans notre manière d’appréhender ce modèle nous partons du principe que l’écriture n’implique pas nécessairement une lecture, forçant ainsi l’acteur à soumettre une opération de lecture pour pouvoir vérifier que son opération d’écriture a bien été prise en compte. Ce point est important puisque la cohérence du point de vue de l’utilisateur sera conditionné par ces opérations de lecture.

L’application de ce modèle sur un seul acteur résultera donc en une suite finit d’opérations d’écritures et de lectures, pour terminer par une suite de lecture infinies (qui est le moment où l’utilisateur arrête d’éditer le document).

\begin{math}
    w('he') \cdot r/\{'he'\} \cdot w('llo') \cdot r/\{'hello'\}^\omega
\end{math}

\begin{figure}[! h]
    \centering
    \resizebox{0.5\columnwidth}{!}{
        \input{images/local1_tzk.tex}
    }
    \caption{Modification local d'un document}
    \label{local_1}
\end{figure}

On voit sur la figure \ref{local_1} que le noeud émet deux requêtes atomiques de modification $w('h')$ et $w('e')$ (regroupées sous la forme d'une seule pour soucis de lisibilité). Il réalise ensuite une requête de lecture $r/\{'h','e'\}$ qui lui permet de vérifier que ses modifications ont bien été prises en compte. Puis il écrit $w('llo')$ et récupère un retour en lisant $r/\{'h','e','l','l','o'\}$ qui lui permet de vérifier que ses modifications ont bien été prises en compte. Il réalise ensuite une suite infinie de lecture $r/\{'h','e','l','l','o'\}^\omega$ correspondant à la consultation du document sur un temps infini.

Cette modélisation nous permet de mettre en avant les points critiques dans la mise en place d'une expérience cohérente pour l'utilisateur. Dans un premier temps nous pouvons nous concentrer sur le lien entre les écritures et les lectures :

Lorsque l'utilisateur soumet les écritures $w('h')$ et $w('e')$ il lui attribue une notion d'ordre. L'écriture de $w('h')$ est donc antérieur à celle de $w('e')$, il serait donc incohérent que au moment de la lecture qui suit, l'utilisateur constate un ordre différent. Cela représente une première propriété de la cohérence séquentielle, la préservation de l'ordre entre les écritures.

Une seconde propriété est la préservation de la validité des écritures. C'est-à-dire que si l'utilisateur soumet une écriture $w('h')$ et une écriture $w('e')$ il s'attend à ce que la lecture qui suit retourne un état qui contient uniquement $'h'$ et $'e'$. Il serait en effet incohérent de recevoir tout autre état.

La troisième propriété est la préservation de la cohérence entre les lectures, c'est-à-dire que si l'utilisateur lit à un instant $t$ un état $\alpha$, alors toutes lectures réalisées à un instant $t' > t$ doivent retourner un état $\beta$ tel que $\alpha \subseteq \beta$.

Ces trois propriétés sont celles définit par Lamport [REF LAMPORT89] et permettent de définir ce qu'il nomme "registre atomique".

\fbox{
    \begin{minipage}{0.94\linewidth}
        \paragraph{Un registre}
        est une structure mathématique qui sert d'abstraction pour parler d'un système qui permet de réaliser des opérations d'écritures et de lectures. L'approche du registre permet de se concentrer sur le point de vue d'un client sans considérer les aspects topologiques du système. Il est donc tout trouvé pour spécifier les problématiques liées à la cohérence dans les systèmes distribués.
    \end{minipage}
}


Le registre atomique de lamport permet de définir le comportement attendu dans un système SWMR (Single Writer Multiple Reader). C'est-à-dire un système où un seul acteur peut écrire et plusieurs peuvent lire. Ce modèle est pertinent dans notre cas d'édition à un seul acteur puisque nous avons un acteur qui écrit et un acteur qui lit (en l'occurrence toujours le même).

\emph{TODO : Résumer papier Lamport89}

Dans un cas d’usage courant, une application d’édition local ne présente pas de problèmes liés à la présence de plusieurs éditeurs en simultanés. Il y a en effet une seule interface homme-machine, c’est-à-dire de façon pragmatique un unique écran et clavier.

Imaginons ainsi un cas où Alice et Bob souhaitent éditer ensemble un même document. Si on voulait simplement appliquer le fonctionnement local que nous venons de décrire à cette nouvelle problématique. Il conviendrait de simplement rajouter une IHM à Alice. Ainsi il y a toujours une seule application d’édition collaborative sur lequel viennent se connecter cette fois-ci deux interfaces (comme visible dans la figure \ref{local_2}).

\begin{figure}[! h]
\begin{multicols}{2}
    
        \centering
        \resizebox{!}{.7\columnwidth}{
            \input{images/local2.latex}
        }
        \caption{Alice et Bob éditent un document localement}
        \label{local_2}
        
        \columnbreak

        \centering
        \resizebox{!}{.8\columnwidth}{
            \input{images/local2fail.latex}
        }
        \caption{Alice et Bob éditent un document localement de manière concurrente}
        \label{local_2_fail}
    \end{multicols}
\end{figure}


Nous avons à présents deux acteurs qui éditent et lisent le document, et un autre qui s’occupe de stocker et de synchroniser le document entre ces deux acteurs.

La limite liée à cette approche réside dans le fait que les communications entre Alice et l’application et Bob et l’application ne peuvent pas être garantis comme équitables. En effet, Alice et Bob peuvent très bien se retrouver déconnectés de manière non prévisible et asynchrone. Ou bien avoir des temps de transmissions de leurs informations qui diffèrent. Le caractère non-deterministe de ces erreurs peut résulter en des incohérences dans l’ordre d’arrivée des informations soumises par Alice et Bob. Ce qui peut a terme créer des incohérences dans le document final.

C’est néanmoins une problématique qui peut être assimilée à de la gestion de la concurrence entre processus. C’est en effet un domaine qui est étudié depuis l’apparition des premiers processeurs multi-cœur. Une approche que nous pouvons donc prendre à la programmation concurrente serait de résoudre ce problème en venant utiliser des techniques de synchronisation de processus. C’est-à-dire en utilisant des mécanismes de synchronisation tel que des verrous dans notre application. On peut par exemple utiliser des sémaphores pour gérer les accès concurrents à la mémoire partagée. Ce qui résulterait en l’exécution suivante :

\begin{figure}[! h]
    \centering
    \resizebox{!}{.7\columnwidth}{
        \input{images/serialized.latex}
    }
    \caption{Alice et Bob éditent un document localement avec des vérrous}
    \label{serialized}
\end{figure}

On voit sur la figure \ref{serialized} que les actions d’Alice et Bob sont sérialisés. C’est-à-dire que les actions d’Alice et Bob sont exécutés l’une après l’autre. Ce qui permet d’éviter les problèmes de concurrence entre les deux acteurs. Cependant, cette approche est très limitée. En effet, elle ne permet pas de profiter des avantages de l’édition collaborative. En effet, cela signifie que l’un des deux acteurs doit attendre que l’autre ait fini d’éditer le document pour pouvoir à son tour l’éditer. Ce qui rabaisse les performances de l’application à la latence de l’acteur le plus lent.

En revenons dans notre contexte initial qui est une application d’édition collaborative nous souhaitons pouvoir gérer un grand nombre d’utilisateur en simultanés. Ainsi la probabilité d’avoir une expérience dégradée pour l’ensemble des utilisateurs croit avec le nombre d’utilisateur. Pour pallier à ce problème l’approche qui peut être adopté est d’exclure les utilisateurs possédant des connexions trop limités avec le serveur.

C’est néanmoins la seule approche qui nous permet d’obtenir une cohérence absolue autant dans la prise en compte des opérations d’écritures des acteurs que dans le traitement de leurs lectures.

Selon Perrin on se placerait dans une approche qui relèverait de la cohérence séquentielle.

\subsection{Cohérence séquentielle}

% blbla sur la cohérence séquentielle de manière très théorique et fondamentale



\paragraph{Validité}

Dans une application d’édition collaborative on s’attend à ce que toutes les entrées des utilisateurs soient prises en compte. Il nous parait en effet inacceptable que des saisies disparaisses de manière aléatoire durant l’exécution.

Ce principe nous permet d’introduire une première propriété utilisée par Perrin pour définir et classer les différents critères de cohérence qu’est la validité.

La validité peut ainsi être résumé comme la propriété qui permet d’assurer que toutes les saisies réalisées, et seulement elles, soient prises en compte dans l’exécution du système.

Ceci se traduit par l’affichage d’un retour quant à la saisie de bob sur son application. Lui signifiant que son interaction avec l’application à bien était prise en compte, et n’est donc pas passée à la trappe. Elle n’implique néanmoins aucune notion d’ordre dans les saisies, ce qui signifie que les saisies peuvent être réagencées durant l’exécution.

\paragraph{Convergence}

Une autre attente d’une application d’édition collaborative est en quelque sorte sont determinisme sur une durée infinie. On s’attend en effet, une fois toutes les éditions terminés, que le document soit identique pour tous les acteurs. C’est-à-dire que peut importe l’ordre dans lequel les saisies ont été réalisées, le document final doit être identique pour tous les nœuds.

C’est ce que Perrin appelle la convergence qu’il définit plus formellement comment étant la propriété qui assure que si un nombre finit d’ecriture et infini de lecture sont réaliséés, alors tous les nœuds finissent par avoir la même valeur.

\paragraph{Localité D’état}

La dernière propriétée du model de Perrin est la localité d’état.

Elle consiste en le fait que chaque acteur doivent garder une vision local cohérente du système. Par exemple, comme illustrée dans la Figure \ref{local_state}, au fur et à mesure des éditions de Bob, sa vue local va évoluer en conséquence, mais si il recoit à un moment donné une édition d’Alice qui est antérieur à une de ses éditions, alors il doit privilégier sa propre édition. C’est-à-dire que sa vue local doit être cohérente avec son historique d’édition quitte à diverger de la vue local d’Alice.

\begin{figure}[! h]
    \caption{Localité d’état}
    \label{local_state}
\end{figure}