diff --git a/docs/rapport/rapport_etat_art/consistency_criteria/index.tex b/docs/rapport/rapport_etat_art/consistency_criteria/index.tex new file mode 100755 index 0000000..c850426 --- /dev/null +++ b/docs/rapport/rapport_etat_art/consistency_criteria/index.tex @@ -0,0 +1,7 @@ +\subsection{Etat des différents critères} +\subsubsection{Les modèles de mémoires partagées} + +\subsubsection{La cohérence forte} +Cohérence Séquentielle \cite{lamport_how_1979} + +\subsubsection{La cohérence Faible} diff --git a/docs/rapport/rapport_etat_art/intro/index.tex b/docs/rapport/rapport_etat_art/intro/index.tex new file mode 100755 index 0000000..7b80510 --- /dev/null +++ b/docs/rapport/rapport_etat_art/intro/index.tex @@ -0,0 +1,5 @@ +\subsection{Motivation} +\input{intro/motivation.tex} + +\subsection{Introduction} +\input{intro/intro.tex} \ No newline at end of file diff --git a/docs/rapport/rapport_etat_art/intro/intro.tex b/docs/rapport/rapport_etat_art/intro/intro.tex new file mode 100644 index 0000000..576e4b1 --- /dev/null +++ b/docs/rapport/rapport_etat_art/intro/intro.tex @@ -0,0 +1,18 @@ +L'étude du comportement des systèmes distribués date des années 1970 avec l'arrivé des premiers processeurs multicoeur. +Il semblait essentiel à l'époque de pouvoir répartir une tâche entre plusieurs acteurs de manières +asynchrone afin d'accroitre les performances. +Ainsi Lamport définit un model de cohérence qu'il nomme "séquentiel". C'est à dire que, une tâche pouvant être découper en un +ensemble d'opération, chaque opération étant répartit entre plusieurs acteurs, il est possible de resequentialiser ces opérations +de facon à ce qu'infine leurs remaniement séquentiel soit indicernable vis-à-vis de ce qui pourait être attendu de +l'éxécution de la même tache dans un environement non distribués. + +Le désaventage de cette approche est qu'elle nécéssite de garder une synchronicité forte entre les acteurs. +La difficulté à préserver cette synchronicité croit considérablement avec le nombre d'acteur et la latence entre eux. L'usage d'une approche séquentiel sur des applications visant à faire travailler des +acteurs distant à travers un réseau mondia tel qu'internet semble à ce titre loin d'être efficace. Et restreint ces dernières +à des usages limités où une faible intéractivité doit être acceptée par les concepteurs. + +Néanmoins là ou l'approche séquentiel est la seule fournissant une cohénce absolue dans la gestions des données du point de vue +général et du point de vue de l'utilisateur. +Il est possibe d'accepter une perte de cette cohérence partiel ou total afin de gagner en performances sur des applications a grande echelle. +Ce compromis entre cohérence et performances est l'objet de ce document qui vise à faire un état du paysage des différentes approches et solutions +existantes, en définissant les cas d'usages associés. \ No newline at end of file diff --git a/docs/rapport/rapport_etat_art/intro/motivation.tex b/docs/rapport/rapport_etat_art/intro/motivation.tex new file mode 100644 index 0000000..11163be --- /dev/null +++ b/docs/rapport/rapport_etat_art/intro/motivation.tex @@ -0,0 +1,9 @@ +La plupart des applications colaborarifs sur le marché fonctionnent sous la forme d'une entité centralisé qui traite les données, les redistribuent aux différents client et résoud les problèmes de cohérences. +De manière à favorisé l'intéractivité de l'applications et ainsi fournir l'experience utilisateur la plus optimal, on constate que certaines de ces application font appels à des algorithmes qui ne respectent pas ce qu'on attendrait d'une éxécution séquentielles, pouvant ainsi menés à des incohérences dans les éxécutions. +Et infine avoir un impact sur l'experience utilisateur. + +Il nous semble donc intéressant de se pencher sur l'état de la rechecrhe concernant les divers manières d'aborder ce compromis dans la gestion de la cohérence dans ce genre de systèmes. Et ainsi mettre en avant les différentes propriétés qui en résultents. L'intérét ici est de fournir une base permettant d'éclairer la prise de décision lors de l'implémentation d'un algorithme visant à satisfaire un problèmes distribué. + +Ce document à était réalisé dans le cadre de mon stage de fin d'étude de Master. +L'objectif est de fournir un état de l'art de la recherches autour des différents compromis réalisables dans la gestion de la cohérence dans le contexte d'applications distribués. +Il à pour but de servir de base à un projet de thèse en CIFRE financé par l'entreprise Scille SAS, et encadré par le Laboratoire d'Informatique et Système. \ No newline at end of file diff --git a/docs/rapport/rapport_etat_art/main.tex b/docs/rapport/rapport_etat_art/main.tex new file mode 100755 index 0000000..0be1ec6 --- /dev/null +++ b/docs/rapport/rapport_etat_art/main.tex @@ -0,0 +1,42 @@ +\documentclass{article} + +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage[french]{babel} +\usepackage[affil-it]{authblk} +\usepackage{fullpage} +\usepackage{graphicx} + +\usepackage{biblatex} +\addbibresource{../../recherches/Stage.bib} + +\begin{document} + +\title{Critères de Cohérence faible byzantine appliquée aux environements cloud} +\author{JOLY Amaury \\ \textbf{Encadrants :} GODARD Emmanuel, TRAVERS Corentin} +\affil{Aix-Marseille Université, Scille} +\date{\today} + +\begin{titlepage} + \maketitle +\end{titlepage} + +\begin{abstract} + lorem ipsum dolor sit amet. +\end{abstract} + +\newpage + +\tableofcontents + +\newpage + +\section{Introduction} +\input{intro/index.tex} + +\section{Les critères de cohérence} +\input{consistency_criteria/index.tex} + +\printbibliography + +\end{document} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/acquis/index.tex b/docs/rapport/rapport_stage/acquis/index.tex new file mode 100644 index 0000000..86e2d9a --- /dev/null +++ b/docs/rapport/rapport_stage/acquis/index.tex @@ -0,0 +1,13 @@ +\subsection{Sécurité des Systèmes d'Information} + +Ce stage à étais pour moi l'opportunité de m'intéresser à la science de l'informatique appliquée aux systèmes distribuée. J'ai pu ainsi découvrir comment mesurer la fiabilité et la cohérence dans ces systèmes, tout en en appréciant les enjeux. J'ai ainsi pu développer une sensibilité dans ma manière d'aborder les applications distribuée, me permettant d'avoir un regard plus critique sur les choix de conceptions de ces derniers. + +Dans le même temps, mes contacts avec l'équipe de Scille m'ont permis de découvrir les enjeux du développement à un stade précoce d'une application orientée sécurité. Mon intégration à ce projet m'a permis de développer un réflexe critique dans la manière dont j'envisage la conception de l'éditeur collaboratif. Devant à tout pris le rendre cohérent avec le produit sur lequel il vise à être greffé. + +Cela à étais aussi l'occasion pour moi de découvrir des types d'attaques particuliers et propres aux systèmes distribués, ainsi que des techniques permettant de contourner la sécurité de réseaux dans le but de réaliser des communications en pair à pair. + +\subsection{Compétences transverses} + +Durant ce stage, j'ai pu perfectionner ma maitrise du LaTeX et notamment la modélisation de schémas. J'ai eu à de nombreuses occasions l'opportunité de m'exprimer devant un auditoire ce qui m'a énormément apporté en aisance à l'oral et en maitrise de mon sujet. + +Ayant travaillé seul en autonomie la plupart de mon temps, j'ai aussi du mettre en place une certaine rigueur et organisation autour de mon travail. Et trouver un équilibre dans l'organisation de mes tâches et de mes pauses. \ No newline at end of file diff --git a/docs/rapport/rapport_stage/bilan/index.tex b/docs/rapport/rapport_stage/bilan/index.tex new file mode 100644 index 0000000..706188b --- /dev/null +++ b/docs/rapport/rapport_stage/bilan/index.tex @@ -0,0 +1,12 @@ +Mon sentiment vis-à-vis de ce stage est globalement positif. J'ai pu comprendre de manière plus profonde le fonctionnement et l'organisation de la recherche en Informatique ce qui était pour moi l'objectif principal. + +Je me suis pris de passion pour le sujet que j'ai eu à traiter et j'ai hâte de poursuivre mon travail dans le cadre de la thèse. + +Mon intégration avec Scille est aussi très positive et je les remercie énormément pour la confiance qu'ils me portent et l'importance du rôle qu'ils me donnent. J'ai réellement le sentiment de faire partie de l'équipe et du projet et c'est quelque chose de très gratifiant. + +Mes regrets vis-à-vis de ce stage porte plutôt sur le début durant lequel j'ai dû me construire un rythme qui n'a pas était évident à trouver. +Les premières semaines on était éprouvante au point de remettre en question mon engagement dans cette voie. Il m'a fallu m'approprier le sujet et gérer d'une meilleure manière mes sessions de travail avant d'arriver à m'épanouir dans ce projet. + +J'aurais aussi aimé apporter une contribution plus importante à Parsec. Je trouve ne pas avoir eu le temps d'acquérir une maitrise du produit suffisante pour être pleinement capable d'y projeter mon travail. + +Je suis très reconnaissant envers mes encadrants pour leurs présences et leurs bienveillances à mon égard. Ils m'on était d'une aide capitale autant vis-à-vis de mon travail que d'un point de vue personnel et c'est avec joie et confiance que je m'engage dans une thèse avec eux. \ No newline at end of file diff --git a/docs/rapport/rapport_stage/images/carte_criteres.png b/docs/rapport/rapport_stage/images/carte_criteres.png new file mode 100755 index 0000000..cd71ddc Binary files /dev/null and b/docs/rapport/rapport_stage/images/carte_criteres.png differ diff --git a/docs/rapport/rapport_stage/intro/index.tex b/docs/rapport/rapport_stage/intro/index.tex new file mode 100644 index 0000000..d7b46dd --- /dev/null +++ b/docs/rapport/rapport_stage/intro/index.tex @@ -0,0 +1,25 @@ +Le stage a était réalisé dans le cadre d'une collaboration entre le LIS et l'entreprise Scille SAS. Il a pour objectif la réalisation d'un travail d'état de l'art d'un sujet au vu de son traitement dans une thèse ultérieur. + +\subsection{Présentation de l'entreprise} +Scille\cite{scille} est une startup Française d'une dizaine d'employés localisée à Bordeaux et travaillant majoritairement dans une politique de télétravail. +Elle développe le produit Parsec, qui est une solution reposant sur une architecture client-serveur hébergée dans le cloud, et visant à fournir un service d'hébergement et de partage de fichier. +Parsec se démarque de ses concurrents, en proposant une solution répondant à un haut niveau de sécurité et en adoptant une approche en source ouverte, le rendant ainsi facilement auditable pour leurs clients. +Ainsi le projet s'encre dans une conception dite de zero-trust en proposant un chiffrement de bout en bout des données, rendant ainsi le serveur incapable de consulter le contenu des données qu'il stocke. Son rôle se limite donc à celui de "relai" entre les clients ainsi que de support de stockage pour le chiffré des données. + +Parsec répond aux critères nécessaires à l'obtention de la certification ANSSI-CSPN-2021/08\cite{scilleCSPN}, avec pour objectif de toucher un marché d'entreprise national ayant un besoin d'échanger des fichiers répondant à des prérequis importants en termes de confidentialités tel que pour la santé, le juridique ou encore l'industrie et le militaire. + +\subsection{Présentation du Sujet} +Scille souhaite développer le produit Parsec de manière à rajouter un service de suite bureautique au service principale qui est le partage de fichier. +À ce titre leur premier besoin est la réalisation d'un outil de traitement de texte. + +L'objectif est de fournir une interface permettant l'édition des fichiers présents dans un espace de travail Parsec dans une approche collaborative et en conservant les propriétés de sécurité de l'application principale. C'est-à-dire en restant dans une approche zero-trust et donc chiffré de bout en bout. + +Ce projet fait l'objet d'une proposition de thèse émise par Scille et encadrée par le Laboratoire d'Informatique et Système. C'est dans ce cadre que c'est effectué mon stage, qui à pour objectif principal la réalisation d'un état de l'art sur ces questions. Et comme objectif secondaire mon intégration à l'organisme finançant ma potentielle thèse. + +\subsection{Bref résumé du stage} +Mon stage a débuté en avril 2023. J'ai commencé par étudier les pistes fournit par mes encadrants, dont majoritairement le livre de Mathieu Perrin \textit{Concurrence et Cohérence dans les Systèmes repartis} \cite{perrin_concurrence_2017}. +Suite à ça j'ai réalisé des recherches sur des sujets connexes, en jonglant ainsi entre lecture de la littérature scientifique et réalisation de présentations orales. Me permettant ainsi d'affiner ma compréhension et de rendre compte de mes avancements à mes encadrants. + +Une fois une maitrise satisfaisante du sujet obtenu, j'ai pu commencer à essayer d'affiner le sujet potentiel de la thèse, et de réfléchir à une solution pour la problématique de Scille. + +Ainsi j'ai pu étudier les preuves de concepts réalisés par les ingénieurs en internes à Scille, ainsi qu'aborder la faisabilité en identifiants les outils et algorithmes existants pouvant aider à la réalisation d'une telle application. \ No newline at end of file diff --git a/docs/rapport/rapport_stage/lib.bib b/docs/rapport/rapport_stage/lib.bib new file mode 100644 index 0000000..db3161e --- /dev/null +++ b/docs/rapport/rapport_stage/lib.bib @@ -0,0 +1,312 @@ + +@article{saito_optimistic_2005, + title = {Optimistic Replication}, + volume = {37}, + url = {https://inria.hal.science/hal-01248208}, + doi = {10.1145/1057977.1057980}, + abstract = {Data replication is a key technology in distributed systems that enables higher availability and performance. This article surveys optimistic replication algorithms. They allow replica contents to diverge in the short term to support concurrent work practices and tolerate failures in low-quality communication links. The importance of such techniques is increasing as collaboration through wide-area and mobile networks becomes popular.Optimistic replication deploys algorithms not seen in traditional “pessimistic” systems. Instead of synchronous replica coordination, an optimistic algorithm propagates changes in the background, discovers conflicts after they happen, and reaches agreement on the final contents incrementally.We explore the solution space for optimistic replication algorithms. This article identifies key challenges facing optimistic replication systems---ordering operations, detecting and resolving conflicts, propagating changes efficiently, and bounding replica divergence---and provides a comprehensive survey of techniques developed for addressing these challenges.}, + pages = {42}, + number = {1}, + journaltitle = {{ACM} Computing Surveys}, + author = {Saito, Yasushi and Shapiro, Marc}, + urldate = {2023-06-09}, + date = {2005}, + langid = {english}, + file = {Saito et Shapiro - 2005 - Optimistic Replication.pdf:/home/amaury/Zotero/storage/4WJX5IAN/Saito et Shapiro - 2005 - Optimistic Replication.pdf:application/pdf}, +} + +@article{singh_zeno_nodate, + title = {Zeno: Eventually Consistent Byzantine-Fault Tolerance}, + abstract = {Many distributed services are hosted at large, shared, geographically diverse data centers, and they use replication to achieve high availability despite the unreachability of an entire data center. Recent events show that non-crash faults occur in these services and may lead to long outages. While Byzantine-Fault Tolerance ({BFT}) could be used to withstand these faults, current {BFT} protocols can become unavailable if a small fraction of their replicas are unreachable. This is because existing {BFT} protocols favor strong safety guarantees (consistency) over liveness (availability).}, + author = {Singh, Atul and Fonseca, Pedro and Kuznetsov, Petr and Rodrigues, Rodrigo and Maniatis, Petros}, + langid = {english}, + file = {Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:/home/amaury/Zotero/storage/K6J2UEBK/Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:application/pdf}, +} + +@inproceedings{shakarami_refresh_2019, + title = {Refresh Instead of Revoke Enhances Safety and Availability: A Formal Analysis}, + volume = {{LNCS}-11559}, + url = {https://inria.hal.science/hal-02384596}, + doi = {10.1007/978-3-030-22479-0_16}, + shorttitle = {Refresh Instead of Revoke Enhances Safety and Availability}, + abstract = {Due to inherent delays and performance costs, the decision point in a distributed multi-authority Attribute-Based Access Control ({ABAC}) system is exposed to the risk of relying on outdated attribute values and policy; which is the safety and consistency problem. This paper formally characterizes three increasingly strong levels of consistency to restrict this exposure. Notably, we recognize the concept of refreshing attribute values rather than simply checking the revocation status, as in traditional approaches. Refresh replaces an older value with a newer one, while revoke simply invalidates the old value. Our lowest consistency level starts from the highest level in prior revocation-based work by Lee and Winslett ({LW}). Our two higher levels utilize the concept of request time which is absent in {LW}. For each of our levels we formally show that using refresh instead of revocation provides added safety and availability.}, + eventtitle = {33th {IFIP} Annual Conference on Data and Applications Security and Privacy ({DBSec})}, + pages = {301}, + publisher = {Springer International Publishing}, + author = {Shakarami, Mehrnoosh and Sandhu, Ravi}, + urldate = {2023-06-09}, + date = {2019-07-15}, + langid = {english}, + file = {Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:/home/amaury/Zotero/storage/XQNWKF7H/Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:application/pdf}, +} + +@article{misra_axioms_1986, + title = {Axioms for memory access in asynchronous hardware systems}, + volume = {8}, + issn = {0164-0925, 1558-4593}, + url = {https://dl.acm.org/doi/10.1145/5001.5007}, + doi = {10.1145/5001.5007}, + abstract = {The problem of concurrent accesses to registers by asynchronous components is considered. A set of axioms about the values in a register during concurrent accesses is proposed. It is shown that if these axioms are met by a register, then concurrent accesses to it may be viewed as nonconcurrent, thus making it possible to analyze asynchronous algorithms without elaborate timing analysis of operations. These axioms are shown, in a certain sense, to be the weakest. Motivation for this work came from analyzing low-level hardware components in a {VLSI} chip which concurrently accesses a flip-flop.}, + pages = {142--153}, + number = {1}, + journaltitle = {{ACM} Transactions on Programming Languages and Systems}, + shortjournal = {{ACM} Trans. Program. Lang. Syst.}, + author = {Misra, J.}, + urldate = {2023-06-08}, + date = {1986-01-02}, + langid = {english}, + file = {Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:/home/amaury/Zotero/storage/KZP2774N/Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:application/pdf}, +} + +@article{lamport_interprocess_1986, + title = {On interprocess communication}, + volume = {1}, + issn = {1432-0452}, + url = {https://doi.org/10.1007/BF01786228}, + doi = {10.1007/BF01786228}, + abstract = {Interprocess communication is studied without assuming any lower-level communication primitives. Three classes of communication registers are considered, and several constructions are given for implementing one class of register with a weaker class. The formalism developed in Part I is used in proving the correctness of these constructions.}, + pages = {86--101}, + number = {2}, + journaltitle = {Distributed Computing}, + shortjournal = {Distrib Comput}, + author = {Lamport, Leslie}, + urldate = {2023-06-08}, + date = {1986-06-01}, + langid = {english}, + keywords = {Communication Network, Computer Hardware, Computer System, Operating System, System Organization}, + file = {Lamport - 1986 - On interprocess communication.pdf:/home/amaury/Zotero/storage/XV7AEARN/Lamport - 1986 - On interprocess communication.pdf:application/pdf}, +} + +@book{lipton_pram_1988, + title = {{PRAM}: A Scalable Shared Memory}, + shorttitle = {{PRAM}}, + pagetotal = {13}, + publisher = {Princeton University, Department of Computer Science}, + author = {Lipton, Richard J. and Sandberg, Jonathan S.}, + date = {1988}, + langid = {english}, + note = {Google-Books-{ID}: 962epwAACAAJ}, + file = {Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:/home/amaury/Zotero/storage/3ZYT3WT4/Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:application/pdf}, +} + +@inproceedings{hutto_slow_1990, + title = {Slow memory: weakening consistency to enhance concurrency in distributed shared memories}, + url = {https://www.computer.org/csdl/proceedings-article/icdcs/1990/00089297/12OmNvSKNPr}, + doi = {10.1109/ICDCS.1990.89297}, + shorttitle = {Slow memory}, + abstract = {The use of weakly consistent memories in distributed shared memory systems to combat unacceptable network delay and to allow such systems to scale is proposed. Proposed memory correctness conditions are surveyed, and how they are related by a weakness hierarchy is demonstrated. Multiversion and messaging interpretations of memory are introduced as means of systematically exploring the space of possible memories. Slow memory is presented as a memory that allows the effects of writes to propagate slowly through the system, eliminating the need for costly consistency maintenance protocols that limit concurrency. Slow memory processes a valuable locality property and supports a reduction from traditional atomic memory. Thus slow memory is as expressive as atomic memory. This expressiveness is demonstrated by two exclusion algorithms and a solution to M.J. Fischer and A. Michael's (1982) dictionary problem on slow memory.}, + eventtitle = {Proceedings.,10th International Conference on Distributed Computing Systems}, + pages = {302,303,304,305,306,307,308,309--302,303,304,305,306,307,308,309}, + publisher = {{IEEE} Computer Society}, + author = {Hutto, P. W. and Ahamad, M.}, + urldate = {2023-06-06}, + date = {1990-01-01}, + file = {Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf:/home/amaury/Téléchargements/Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf:application/pdf}, +} + +@article{lamport_how_1979, + title = {How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs}, + volume = {C-28}, + issn = {1557-9956}, + doi = {10.1109/TC.1979.1675439}, + abstract = {Many large sequential computers execute operations in a different order than is specified by the program. A correct execution is achieved if the results produced are the same as would be produced by executing the program steps in order. For a multiprocessor computer, such a correct execution by each processor does not guarantee the correct execution of the entire program. Additional conditions are given which do guarantee that a computer correctly executes multiprocess programs.}, + pages = {690--691}, + number = {9}, + journaltitle = {{IEEE} Transactions on Computers}, + author = {{Lamport}}, + date = {1979-09}, + note = {Conference Name: {IEEE} Transactions on Computers}, + keywords = {Computer design, concurrent computing, hardware correctness, multiprocessing, parallel processing}, + file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/IVGSSPNE/1675439.html:text/html;Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:/home/amaury/Zotero/storage/GY8CWGUV/Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:application/pdf}, +} + +@article{mosberger_memory_1993, + title = {Memory consistency models}, + volume = {27}, + issn = {0163-5980}, + url = {https://dl.acm.org/doi/10.1145/160551.160553}, + doi = {10.1145/160551.160553}, + abstract = {This paper discusses memory consistency models and their influence on software in the context of parallel machines. In the first part we review previous work on memory consistency models. The second part discusses the issues that arise due to weakening memory consistency. We are especially interested in the influence that weakened consistency models have on language, compiler, and runtime system design. We conclude that tighter interaction between those parts and the memory system might improve performance considerably.}, + pages = {18--26}, + number = {1}, + journaltitle = {{ACM} {SIGOPS} Operating Systems Review}, + shortjournal = {{SIGOPS} Oper. Syst. Rev.}, + author = {Mosberger, David}, + urldate = {2023-06-06}, + date = {1993-01}, + langid = {english}, + file = {Mosberger - 1993 - Memory consistency models.pdf:/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.pdf:application/pdf}, +} + +@inproceedings{hutto_slow_1990-1, + title = {Slow memory: weakening consistency to enhance concurrency in distributed shared memories}, + url = {https://www.computer.org/csdl/proceedings-article/icdcs/1990/00089297/12OmNvSKNPr}, + doi = {10.1109/ICDCS.1990.89297}, + shorttitle = {Slow memory}, + abstract = {The use of weakly consistent memories in distributed shared memory systems to combat unacceptable network delay and to allow such systems to scale is proposed. Proposed memory correctness conditions are surveyed, and how they are related by a weakness hierarchy is demonstrated. Multiversion and messaging interpretations of memory are introduced as means of systematically exploring the space of possible memories. Slow memory is presented as a memory that allows the effects of writes to propagate slowly through the system, eliminating the need for costly consistency maintenance protocols that limit concurrency. Slow memory processes a valuable locality property and supports a reduction from traditional atomic memory. Thus slow memory is as expressive as atomic memory. This expressiveness is demonstrated by two exclusion algorithms and a solution to M.J. Fischer and A. Michael's (1982) dictionary problem on slow memory.}, + eventtitle = {Proceedings.,10th International Conference on Distributed Computing Systems}, + pages = {302,303,304,305,306,307,308,309--302,303,304,305,306,307,308,309}, + publisher = {{IEEE} Computer Society}, + author = {Hutto, P. W. and Ahamad, M.}, + urldate = {2023-06-06}, + date = {1990-01-01}, +} + +@incollection{goos_causal_1995, + location = {Berlin, Heidelberg}, + title = {From causal consistency to sequential consistency in shared memory systems}, + volume = {1026}, + isbn = {978-3-540-60692-5 978-3-540-49263-4}, + url = {http://link.springer.com/10.1007/3-540-60692-0_48}, + pages = {180--194}, + booktitle = {Foundations of Software Technology and Theoretical Computer Science}, + publisher = {Springer Berlin Heidelberg}, + author = {Raynal, Michel and Schiper, André}, + editor = {Thiagarajan, P. S.}, + editorb = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan}, + editorbtype = {redactor}, + urldate = {2023-06-06}, + date = {1995}, + langid = {english}, + doi = {10.1007/3-540-60692-0_48}, + note = {Series Title: Lecture Notes in Computer Science}, + file = {Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:/home/amaury/Zotero/storage/B8UNWUSA/Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:application/pdf}, +} + +@thesis{kumar_fault-tolerant_2019, + title = {Fault-Tolerant Distributed Services in Message-Passing Systems}, + institution = {Texas A\&M University}, + type = {phdthesis}, + author = {Kumar, Saptaparni}, + date = {2019}, + file = {Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:/home/amaury/Zotero/storage/Q9XK77W9/Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:application/pdf;Snapshot:/home/amaury/Zotero/storage/7JB26RAJ/1.html:text/html}, +} + +@article{somasekaram_high-availability_2022, + title = {High-Availability Clusters: A Taxonomy, Survey, and Future Directions}, + volume = {187}, + issn = {01641212}, + url = {http://arxiv.org/abs/2109.15139}, + doi = {10.1016/j.jss.2021.111208}, + shorttitle = {High-Availability Clusters}, + abstract = {The delivery of key services in domains ranging from finance and manufacturing to healthcare and transportation is underpinned by a rapidly growing number of mission-critical enterprise applications. Ensuring the continuity of these complex applications requires the use of software-managed infrastructures called high-availability clusters ({HACs}). {HACs} employ sophisticated techniques to monitor the health of key enterprise application layers and of the resources they use, and to seamlessly restart or relocate application components after failures. In this paper, we first describe the manifold uses of {HACs} to protect essential layers of a critical application and present the architecture of high availability clusters. We then propose a taxonomy that covers all key aspects of {HACs} -- deployment patterns, application areas, types of cluster, topology, cluster management, failure detection and recovery, consistency and integrity, and data synchronisation; and we use this taxonomy to provide a comprehensive survey of the end-to-end software solutions available for the {HAC} deployment of enterprise applications. Finally, we discuss the limitations and challenges of existing {HAC} solutions, and we identify opportunities for future research in the area.}, + pages = {111208}, + journaltitle = {Journal of Systems and Software}, + shortjournal = {Journal of Systems and Software}, + author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar}, + urldate = {2023-06-06}, + date = {2022-05}, + eprinttype = {arxiv}, + eprint = {2109.15139 [cs, eess]}, + keywords = {Computer Science - Distributed, Parallel, and Cluster Computing, Computer Science - Networking and Internet Architecture, Electrical Engineering and Systems Science - Systems and Control}, + file = {arXiv.org Snapshot:/home/amaury/Zotero/storage/B4KCP9BG/2109.html:text/html;Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:/home/amaury/Zotero/storage/K3LQZLC8/Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:application/pdf}, +} + +@book{perrin_concurrence_2017, + title = {Concurrence et cohérence dans les systèmes répartis}, + isbn = {978-1-78405-295-9}, + abstract = {La société moderne est de plus en plus dominée par la société virtuelle, le nombre d’internautes dans le monde ayant dépassé les trois milliards en 2015. A la différence de leurs homologues séquentiels, les systèmes répartis sont beaucoup plus difficiles à concevoir, et sont donc sujets à de nombreux problèmes.La cohérence séquentielle fournit la même vue globale à tous les utilisateurs, mais le confort d\&\#39;utilisation qu\&\#39;elle apporte est trop coûteux, voire impossible, à mettre en oeuvre à grande échelle. Concurrence et cohérence dans les systèmes répartis examine les meilleures façons de spécifier les objets que l’on peut tout de même implémenter dans ces systèmes.Cet ouvrage explore la zone grise des systèmes répartis et dresse une carte des critères de cohérence faible, identifiant plusieurs familles et démontrant comment elles peuvent s’intégrer dans un langage de programmation.}, + pagetotal = {194}, + publisher = {{ISTE} Group}, + author = {Perrin, Matthieu}, + date = {2017-09-01}, + langid = {french}, + note = {Google-Books-{ID}: 6DRlDwAAQBAJ}, + file = {Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:/home/amaury/Téléchargements/Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf:application/pdf}, +} + +@article{van_der_linde_practical_2020, + title = {Practical client-side replication: weak consistency semantics for insecure settings}, + volume = {13}, + issn = {2150-8097}, + url = {https://dl.acm.org/doi/10.14778/3407790.3407847}, + doi = {10.14778/3407790.3407847}, + shorttitle = {Practical client-side replication}, + abstract = {Client-side replication and direct client-to-client synchronization can be used to create highly available, low-latency interactive applications. Causal consistency, the strongest available consistency model under network partitions, is an attractive consistency model for these applications.}, + pages = {2590--2605}, + number = {12}, + journaltitle = {Proceedings of the {VLDB} Endowment}, + shortjournal = {Proc. {VLDB} Endow.}, + author = {Van Der Linde, Albert and Leitão, João and Preguiça, Nuno}, + urldate = {2023-06-06}, + date = {2020-08}, + langid = {english}, + file = {Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:/home/amaury/Zotero/storage/5TJ3SA56/Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:application/pdf}, +} + +@article{decandia_dynamo_nodate, + title = {Dynamo: Amazon’s Highly Available Key-value Store}, + abstract = {Reliability at massive scale is one of the biggest challenges we face at Amazon.com, one of the largest e-commerce operations in the world; even the slightest outage has significant financial consequences and impacts customer trust. The Amazon.com platform, which provides services for many web sites worldwide, is implemented on top of an infrastructure of tens of thousands of servers and network components located in many datacenters around the world. At this scale, small and large components fail continuously and the way persistent state is managed in the face of these failures drives the reliability and scalability of the software systems.}, + author = {{DeCandia}, Giuseppe and Hastorun, Deniz and Jampani, Madan and Kakulapati, Gunavardhan and Lakshman, Avinash and Pilchin, Alex and Sivasubramanian, Swaminathan and Vosshall, Peter and Vogels, Werner}, + langid = {english}, + file = {DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:/home/amaury/Zotero/storage/KDHRPBGR/DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:application/pdf}, +} + +@misc{misra_byzantine_2021, + title = {Byzantine Fault Tolerant Causal Ordering}, + url = {http://arxiv.org/abs/2112.11337}, + abstract = {Causal ordering in an asynchronous system has many applications in distributed computing, including in replicated databases and real-time collaborative software. Previous work in the area focused on ordering point-to-point messages in a fault-free setting, and on ordering broadcasts under various fault models. To the best of our knowledge, Byzantine faulttolerant causal ordering has not been attempted for point-topoint communication in an asynchronous setting. In this paper, we first show that existing algorithms for causal ordering of point-to-point communication fail under Byzantine faults. We then prove that it is impossible to causally order messages under point-to-point communication in an asynchronous system with one or more Byzantine failures. We then present two algorithms that can causally order messages under Byzantine failures, where the network provides an upper bound on the message transmission time. The proofs of correctness for these algorithms show that it is possible to achieve causal ordering for point-to-point communication under a stronger asynchrony model where the network provides an upper bound on message transmission time. We also give extensions of our two algorithms for Byzantine fault-tolerant causal ordering of multicasts.}, + number = {{arXiv}:2112.11337}, + publisher = {{arXiv}}, + author = {Misra, Anshuman and Kshemkalyani, Ajay}, + urldate = {2023-07-12}, + date = {2021-12-21}, + langid = {english}, + eprinttype = {arxiv}, + eprint = {2112.11337 [cs]}, + keywords = {Computer Science - Distributed, Parallel, and Cluster Computing}, + file = {Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:/home/amaury/Zotero/storage/P2R366US/Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:application/pdf}, +} + +@inproceedings{tseng_distributed_2019, + title = {Distributed Causal Memory in the Presence of Byzantine Servers}, + doi = {10.1109/NCA.2019.8935059}, + abstract = {We study distributed causal shared memory (or distributed read/write objects) in the client-server model over asynchronous message-passing networks in which some servers may suffer Byzantine failures. Since Ahamad et al. proposed causal memory in 1994, there have been abundant research on causal storage. Lately, there is a renewed interest in enforcing causal consistency in large-scale distributed storage systems (e.g., {COPS}, Eiger, Bolt-on). However, to the best of our knowledge, the fault-tolerance aspect of causal memory is not well studied, especially on the tight resilience bound. In our prior work, we showed that 2 f+1 servers is the tight bound to emulate crash-tolerant causal shared memory when up to f servers may crash. In this paper, we adopt a typical model considered in many prior works on Byzantine-tolerant storage algorithms and quorum systems. In the system, up to f servers may suffer Byzantine failures and any number of clients may crash. We constructively present an emulation algorithm for Byzantine causal memory using 3 f+1 servers. We also prove that 3 f+1 is necessary for tolerating up to f Byzantine servers. In other words, we show that 3 f+1 is a tight bound. For evaluation, we implement our algorithm in Golang and compare their performance with two state-of-the-art fault-tolerant algorithms that ensure atomicity in the Google Cloud Platform.}, + eventtitle = {2019 {IEEE} 18th International Symposium on Network Computing and Applications ({NCA})}, + pages = {1--8}, + booktitle = {2019 {IEEE} 18th International Symposium on Network Computing and Applications ({NCA})}, + author = {Tseng, Lewis and Wang, Zezhi and Zhao, Yajie and Pan, Haochen}, + date = {2019-09}, + note = {{ISSN}: 2643-7929}, + keywords = {asynchrony, Byzantine faults, causal memory, Computer crashes, Consensus protocol, distributed storage system, Emulation, evaluation, Fault tolerance, Fault tolerant systems, History, Servers, tight condition}, + file = {IEEE Xplore Abstract Record:/home/amaury/Zotero/storage/DDV34ULW/8935059.html:text/html}, +} + +@misc{scille, + author = {Scille}, + howpublished = "\url{https://parsec.cloud}", +} + +@misc{scilleCSPN, + author = {Scille}, + howpublished = "\url{https://parsec.cloud/wp-content/uploads/2022/11/20210421-Certification-ANSSI-CSPN-2021-08-PARSEC-2.0.0.pdf}", +} +@misc{GoogleDoc, + author = {Google}, + howpublished = "\url{https://docs.google.com}", +} +@misc{Office365, + author = {Microsoft}, + howpublished = "\url{https://office.com}", +} +@misc{OnlyOffice, + author = {Scille}, + howpublished = "\url{https://onlyoffice.com}", +} + +@inproceedings{shapiro2011conflict, + title={Conflict-free replicated data types}, + author={Shapiro, Marc and Pregui{\c{c}}a, Nuno and Baquero, Carlos and Zawirski, Marek}, + booktitle={Stabilization, Safety, and Security of Distributed Systems: 13th International Symposium, SSS 2011, Grenoble, France, October 10-12, 2011. Proceedings 13}, + pages={386--400}, + year={2011}, + organization={Springer} +} + +@inproceedings{ford2005peer, + title={Peer-to-Peer Communication Across Network Address Translators.}, + author={Ford, Bryan and Srisuresh, Pyda and Kegel, Dan}, + booktitle={USENIX Annual Technical Conference, General Track}, + pages={179--192}, + year={2005} +} diff --git a/docs/rapport/rapport_stage/main.ist b/docs/rapport/rapport_stage/main.ist new file mode 100644 index 0000000..357b29b --- /dev/null +++ b/docs/rapport/rapport_stage/main.ist @@ -0,0 +1,29 @@ +% makeindex style file created by the glossaries package +% for document 'main' on 2023-9-7 +actual '?' +encap '|' +level '!' +quote '"' +keyword "\\glossaryentry" +preamble "\\glossarysection[\\glossarytoctitle]{\\glossarytitle}\\glossarypreamble\n\\begin{theglossary}\\glossaryheader\n" +postamble "\%\n\\end{theglossary}\\glossarypostamble\n" +group_skip "\\glsgroupskip\n" +item_0 "\%\n" +item_1 "\%\n" +item_2 "\%\n" +item_01 "\%\n" +item_x1 "\\relax \\glsresetentrylist\n" +item_12 "\%\n" +item_x2 "\\relax \\glsresetentrylist\n" +delim_0 "\{\\glossaryentrynumbers\{\\relax " +delim_1 "\{\\glossaryentrynumbers\{\\relax " +delim_2 "\{\\glossaryentrynumbers\{\\relax " +delim_t "\}\}" +delim_n "\\delimN " +delim_r "\\delimR " +headings_flag 1 +heading_prefix "\\glsgroupheading\{" +heading_suffix "\}\\relax \\glsresetentrylist " +symhead_positive "glssymbols" +numhead_positive "glsnumbers" +page_compositor "." diff --git a/docs/rapport/rapport_stage/main.tex b/docs/rapport/rapport_stage/main.tex new file mode 100644 index 0000000..c254257 --- /dev/null +++ b/docs/rapport/rapport_stage/main.tex @@ -0,0 +1,68 @@ +\documentclass{article} + +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage[french]{babel} +\usepackage[affil-it]{authblk} +\usepackage{fullpage} +\usepackage{graphicx} + +\usepackage{biblatex} +\addbibresource{lib.bib} + +\usepackage{tikz} +\usetikzlibrary{positioning} +\usetikzlibrary{calc} +\usetikzlibrary{arrows.meta} + +\begin{document} + +\title{ + Rapport de Stage Master 2 FSI \\ + \large Critères de Cohérence faible byzantine appliquée aux environnements cloud} +\author{JOLY Amaury \\ \textbf{Encadrants :} Godard Emmanuel, Travers Corentin} +\affil{Aix-Marseille Université, Scille} +\date{\today} + +\begin{titlepage} + \maketitle + + \begin{abstract} + J'ai réalisé ce stage au Laboratoire d'Informatique et Système sous l'encadrement d'Emmanuel Godard et Corentin Travers. + + L'objectif à étais de fournir les bases théoriques à la réalisation d'une thèse CIFRE en collaboration entre l'entreprise Scille et le laboratoire. + La thèse à pour but d'étudier les critères de cohérence faible et d'appliquer ces recherches au développement d'une application permettant l'édition collaborative sur des documents textes sans intermédiaire de confiance. + \end{abstract} + + +\end{titlepage} + +\tableofcontents + +\newpage + +\section{Présentation du Sujet} +\input{intro/index.tex} + +\newpage + +\section{Travail accomplit} +\input{travail/index.tex} + +\newpage + +\section{Acquis} +\input{acquis/index.tex} + +\section{Bilan} +\input{bilan/index.tex} + +\newpage + +\printbibliography + +\newpage + +\listoffigures + +\end{document} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/convergence.tex b/docs/rapport/rapport_stage/schemas/convergence.tex new file mode 100755 index 0000000..06c53aa --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/convergence.tex @@ -0,0 +1,35 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(1)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(0)$}; + \node[roundnode] (13) [right=35pt of 12] {}; + \node[above] at (13.north) {$R/\{\emptyset\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(2)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{2\}$}; + \node[roundnode] (23) [right=35pt of 22] {}; + \node[below] at (23.south) {$R/\{\emptyset\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + + \draw (23) -- (13); + + \draw[dashed] ($(13)!0.5!(12) + (0,1)$) -- ++(0, -2.9); + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/ensemble.tex b/docs/rapport/rapport_stage/schemas/ensemble.tex new file mode 100644 index 0000000..a0717ae --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/ensemble.tex @@ -0,0 +1,29 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(0)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(1)$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$I(2)$}; + \node[roundnode] (15) [right=of 13] {}; + \node[above] at (15.north) {$R/\{0,1,2\}$}; + \node[roundnode] (16) [right=of 15] {}; + \node[above] at (16.north) {$D(1)$}; + \node[roundnode] (17) [right=of 16] {}; + \node[above] at (17.north) {$R/\{0,2\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + \draw[arrow] (13) -- (15); + \draw[arrow] (15) -- (16); + \draw[arrow] (16) -- (17); + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/ensemble_2.tex b/docs/rapport/rapport_stage/schemas/ensemble_2.tex new file mode 100644 index 0000000..799bac6 --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/ensemble_2.tex @@ -0,0 +1,35 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(0)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(2)$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$D(1)$}; + \node[roundnode] (14) [right=of 13] {}; + \node[above] at (14.north) {$R/\{0,2\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + \draw[arrow] (13) -- (14); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(1)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{0,1,2\}$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) {$R/\{0,2\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/ensemble_2_lin.tex b/docs/rapport/rapport_stage/schemas/ensemble_2_lin.tex new file mode 100644 index 0000000..a028364 --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/ensemble_2_lin.tex @@ -0,0 +1,40 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(0)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(2)$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$D(1)$}; + \node[roundnode] (14) [right=of 13] {}; + \node[above] at (14.north) {$R/\{0,2\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + \draw[arrow] (13) -- (14); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(1)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{0,1,2\}$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) {$R/\{0,2\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + + \draw[message] (21) -- ($(11)!0.5!(12)$); + \draw[message] (11) -- (21); + \draw[message] (12) -- ($(21)!0.5!(22)$); + \draw[message] (13) -- ($(22)!0.5!(23)$); + + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/ensemble_2_lin2.tex b/docs/rapport/rapport_stage/schemas/ensemble_2_lin2.tex new file mode 100644 index 0000000..c8acec9 --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/ensemble_2_lin2.tex @@ -0,0 +1,40 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(0)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(2)$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$D(1)$}; + \node[roundnode] (14) [right=of 13] {}; + \node[above] at (14.north) {$R/\{0,2\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + \draw[arrow] (13) -- (14); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(1)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{0,1,2\}$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) {$R/\{0,2\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + + \draw[message] (21) -- ($(12)!0.5!(13)$); + \draw[message] (11) -- ($(21)!0.33!(22)$); + \draw[message] (12) -- ($(21)!0.66!(22)$); + \draw[message] (13) -- ($(22)!0.5!(23)$); + + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/localiteetat.tex b/docs/rapport/rapport_stage/schemas/localiteetat.tex new file mode 100755 index 0000000..1dc0ddc --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/localiteetat.tex @@ -0,0 +1,34 @@ +\resizebox{\columnwidth}{!}{% + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(0)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$R/\{\emptyset\}$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$R/\{1\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(1)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{\emptyset\}$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) {$R/\{0\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + + \draw[message] (11) -- ($(22)!0.5!(23)$); + \draw[message] (21) -- ($(12)!0.5!(13)$); + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/pipeline.tex b/docs/rapport/rapport_stage/schemas/pipeline.tex new file mode 100644 index 0000000..4de6ff9 --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/pipeline.tex @@ -0,0 +1,43 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$D(1)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(1)$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$D(1)$}; + \node[roundnode] (14) [right=of 13] {}; + \node[above] at (14.north) {$R/\{1\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + \draw[arrow] (13) -- (14); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(1)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{\emptyset\}$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) {$R/\{1\}$}; + \node[roundnode] (24) [right=of 23] {}; + \node[below] at (24.south) {$R/\{\emptyset\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + \draw[arrow] (23) -- (24); + + \draw[message] (21) -- ($(13)!0.5!(14)$); + \draw[message] (11) -- ($(21)!0.5!(22)$); + \draw[message] (13) -- ($(23)!0.5!(24)$); + \draw[message] (12) -- ($(22)!0.5!(23)$); + + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/pipeline_crdt.tex b/docs/rapport/rapport_stage/schemas/pipeline_crdt.tex new file mode 100644 index 0000000..d67259f --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/pipeline_crdt.tex @@ -0,0 +1,43 @@ +\resizebox{\columnwidth}{!}{ + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(O_1)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$I(O_2)$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$I(O_3)$}; + \node[roundnode] (14) [right=50pt of 13] {}; + \node[above] at (14.north) {$R/\{O_0, O_1, O_2, O_3\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + \draw[arrow] (13) -- (14); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$I(1)$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$R/\{O_0, O_1\}$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) [below=15pt] {$R/\{O_0, O_1, O_2\}$}; + \node[roundnode] (24) [right=50pt of 23] {}; + \node[below] at (24.south) {$R/\{O_0, O_1, O_2, O_3\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + \draw[arrow] (23) -- (24); + + \draw[message] (21) -- ($(13)!0.5!(14)$); + \draw[message] (11) -- ($(21)!0.5!(22)$); + \draw[message] (13) -- ($(23)!0.5!(24)$); + \draw[message] (12) -- ($(22)!0.5!(23)$); + + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/schemas/validite.tex b/docs/rapport/rapport_stage/schemas/validite.tex new file mode 100755 index 0000000..f3f9d38 --- /dev/null +++ b/docs/rapport/rapport_stage/schemas/validite.tex @@ -0,0 +1,31 @@ +\resizebox{\columnwidth}{!}{% + \begin{tikzpicture}[ + roundnode/.style={circle, draw=black, fill=black, very thick, minimum size=1pt,}, + ignorednode/.style={circle, draw=black!20, fill=black!20, very thick, minimum size=1pt,}, + arrow/.style={|->, thick,}, + message/.style={->, blue!50, dashed, -{Circle[length=4pt,]}}, + ] + + \node[roundnode] (11) {}; + \node[left] at (11.west) {$p_0$}; + \node[above] at (11.north) {$I(1)$}; + \node[roundnode] (12) [right=of 11] {}; + \node[above] at (12.north) {$R/\{1\}$}; + \node[roundnode] (13) [right=of 12] {}; + \node[above] at (13.north) {$R/\{1\}$}; + + \draw[arrow] (11) -- (12); + \draw[arrow] (12) -- (13); + + \node[roundnode] (21) [below=10pt of 11] {}; + \node[left] at (21.west) {$p_1$}; + \node[below] at (21.south) {$R/\{1\}$}; + \node[roundnode] (22) [right=of 21] {}; + \node[below] at (22.south) {$D(1)$}; + \node[roundnode] (23) [right=of 22] {}; + \node[below] at (23.south) {$R/\{\emptyset\}$}; + + \draw[arrow] (21) -- (22); + \draw[arrow] (22) -- (23); + \end{tikzpicture} +} \ No newline at end of file diff --git a/docs/rapport/rapport_stage/travail/index.tex b/docs/rapport/rapport_stage/travail/index.tex new file mode 100644 index 0000000..aec05d6 --- /dev/null +++ b/docs/rapport/rapport_stage/travail/index.tex @@ -0,0 +1,243 @@ +\subsection{L'étude de la cohérence des données dans les applications distribuée} + +La première étape de la réalisation de mon stage a était la lecture et compréhension de la littérature mise en lien avec le sujet du stage. Le sujet sous-jacent à ces différentes sources peut être résumé à l'étude de la \textbf{cohérence dans des systèmes répartis en milieu malicieux}. + +Il semble essentiel dans un premier temps d'expliquer cet énoncé et de faire le lien avec notre projet plus concret. + +En tant qu'application collaborative en temps réel, notre problème doit impliquer une application distribuée. C'est-à-dire une suite de procédure sous la forme d'un algorithme qui pourra être exécutés par l'ensemble des membres collaborant et qui aura comme objectif la synchronisation des informations entre les utilisateurs. + +Ce genre d'application nécessite de manière intrinsèque une architecture dite distribuée. On formalisera ainsi un système distribué comme étant un ensemble de nœud capable d'échanger de l'information les uns avec les autres au vu de réaliser une tâche commune. + +Les applications collaboratives grand public actuelles (Google Doc \cite{GoogleDoc}, Office365 \cite{Office365}, OnlyOffice \cite{OnlyOffice}) utilisent une approche de synchronisation entre les utilisateurs qui imite un comportement similaire à une exécution sans collaboration. Elles utilisent ainsi une architecture client-serveur. Chaque opération d'écriture et de lecture du document soumise par le client doit être validé en amont par le serveur qui s'assurera de la préservation de la cohérence du document entre chaque membre à chaque instant. En d'autres termes avec cette approche si on prend une image de l'état des données stocké par l'ensemble du réseau, alors elle sera identique pour chaque nœud. + +Cette approche est la plus évidente et est la plus proche d'un comportement attendu par un utilisateur sur ce genre d'usage. Mais elle présente tout de même quelques problèmes. +Premièrement elle nécessite que tous les membres possèdent une latence raisonnable, afin de permettre la meilleure interactivité possible. L'ensemble des nœuds du système doivent se baser sur la latence du nœud le plus lent, nuisant à l'interactivité de l'application. Pour éviter cela, les applications exclues les membres possédants des connexions trop lentes limitant donc les utilisateurs potentiels. + +Cette approche n'est pas non plus compatible avec une réplication du serveur sans occasionner une baisse de l'interactivité par la même occasion. Posant ainsi le problème d'un point de faille unique où si le serveur se trouve être inaccessible, l'application ne peut plus être fonctionnel. +Par extension dans le cas d'une segmentation du réseau, les membres n'étant pas sur le segment commun avec le serveur se retrouve exclues de l'application. + +La dernière limitation de cette approche et qu'elle implique que le serveur central ait accès aux données partagé et en soit l'ordonnanceur, ce qui rentre complétement en désaccord avec l'approche zero-trust de Parsec. Cette solution n'est donc pas acceptable, heureusement des compromis sont possibles autorisant des comportements qui serait inacceptable dans un contexte de synchronicité forte entre les nœuds, mais ne nuisant pas nécessairement à notre application finale. Afin d'étudier les différents compromis possibles nous devons donc nous pencher sur l'étude de la cohérence dans les systèmes répartie. + +Nous nous intéressons à la notion de milieu malicieux, c'est-à-dire considérer que n'importe quel nœud du réseau peut se révéler être dissident de la procédure attendue à des fin rationnelle ou non, puisque dans notre contexte, l'application sera distribuée dans un environnement de production et doit donc à ce titre prendre en considération ce genre de cas. + +\subsubsection{Comment étudier la cohérence dans un système répartie} + +L'étude de la cohérence des données dans un système répartie est à différencié de l'étude algorithmique de l'application distribuée sous-jacente. Ce qui nous intéresse dans l'étude de la cohérence est la manière dont les états locaux des différents nœuds évolues dans le temps et non pas la manière avec laquelle nous avons obtenu ces états locaux. Cette nuance est importante puisqu'elle nous force à regarder les changements d'états comme une histoire résultant d'une certaine exécution d'un algorithme sans être biaisé par les spécifications de ce dernier. On ne se base donc plus sur ce que l'algorithme est censé produire, mais sur l'histoire que nous observons. + +Pour observer et décrire ces histoires, nous avons besoin d'un modèle assez simple pour pouvoir être facilement généralisé tout en étant capable d'expliquer la totalité de ce qui peut être observable. Nous utiliserons ainsi la modélisation utiliser par Perrin \cite{perrin_concurrence_2017} dans son ouvrage précédemment cité. +PERRIN définit différents types de données mettant plus ou moins en avant certains comportements. Dans le cadre de ce rapport, nous utiliserons essentiellement l'"ensemble" qui se rapproche le plus de notre objectif final. + +L'ensemble peut être soumis à 3 opérations différentes : +\begin{itemize} + \item L'insertion notée $I(v)$ permet d'insérer l'élément $v$ dans l'ensemble. + \item La suppression notée $D(v)$ permet de retirer l'élément $v$ de l'ensemble. + \item La lecture notée $R$ retourne l'état de l'ensemble. +\end{itemize} + +Par exemple imaginons un système à un seul nœud où les opérations $I(0) \bullet I(1) \bullet I(2) \bullet R \bullet D(1) \bullet R$ sont réalisées. +Nous pouvons modéliser cette exécution comme vue dans la figure \ref{enesmble}. + +\begin{figure}[!h] + \centering + \resizebox*{.75\textwidth}{!}{\input{schemas/ensemble}} + \caption{Exemple d'histoire concurrente à un seul nœud sur un ensemble} + \label{enesmble} +\end{figure} + +Il est important de noter que dans un ensemble, il n'y a pas de notion d'ordre. Si un élément est inséré plusieurs fois dans l'ensemble alors il ne sera présent qu'une unique fois au maximum et ne nécessitera qu'une seule opération de suppression pour être retiré. + +Nous pouvons, à partir de la figure \ref{enesmble} retrouver la liste des opérations qui nous on servit à la produire, c'est-à-dire $I(0) \bullet I(1) \bullet I(2) \bullet R \bullet D(1) \bullet R$. Cette liste d'opération est ce qu'on appelle une linéarisation de l'histoire décrite par la figure. Dans le contexte de l'étude de la cohérence d'un système on ne prend pas une linéarisation existante pour produire une histoire, mais on observe de manière extérieure une histoire et on essaye par la suite de montrer si une linéarisation est possible. + +Reprenons notre exemple en y ajoutant un second nœud. + +\begin{figure}[!h] + \centering + \resizebox*{.5\textwidth}{!}{\input{schemas/ensemble_2}} + \caption{Exemple d'histoire concurrente à 2 nœuds sur un ensemble} + \label{enesmble2} +\end{figure} + +Dans la figure \ref{enesmble2} nous avons répartie les opérations entre plusieurs nœuds. C'est le comportement qu'on pourrait observer dans une application d'édition collaborative par exemple. Mais ici il semble moins évident d'extraire une linéarisation. + +La linéarisation la plus évidente pourrait être montrée sur la figure \ref{enesmble2lin}. + +\begin{figure}[!h] + \centering + \resizebox*{.5\textwidth}{!}{\input{schemas/ensemble_2_lin.tex}} + \caption{Exemple de linéarisation possible} + \label{enesmble2lin} +\end{figure} + +Ici nous imaginons que ce qui à pu produire une telle histoire est l'exécution séquentielle des opérations $I(0) \bullet I(1) \bullet I(2) \bullet R \bullet D(1) \bullet R$. Ce qui ne diffère donc en rien d'une exécution à un seul nœud. La cohérence est entièrement préservée et on ne distingue pas cette exécution d'une exécution similaire réalisée par un unique nœud. + +On parle alors de cohérence forte, ou de cohérence séquentielle. Puisque la linéarisation est indiscernable de celle d'une exécution séquentielle. + +Néanmoins, il est aussi envisageable que l'exécution se soit déroulée comme ce qui est montrée dans la figure \ref{enesmble2linbis}. + +\begin{figure}[!h] + \centering + \resizebox*{.50\textwidth}{!}{\input{schemas/ensemble_2_lin2.tex}} + \caption{Exemple de linéarisation possible} + \label{enesmble2linbis} +\end{figure} + +Ici chaque nœud possède sa propre linéarisation. Du point de vue du nœud 0 l'exécution est linéarisé comme suit $I(0) \bullet I(2) \bullet I(1) \bullet D(1) \bullet R$. Tandis que pour le nœud 1 il s'est plutôt passé l'exécution suivante $I(1) \bullet I(0) \bullet I(2) \bullet R \bullet D(1) \bullet R$. +Ici le résultat final ne change pas, mais les évolutions des états de chaque nœud diverge à certains moments. Dans le cas où l'exécution se serait terminé prématurément, les deux nœuds auraient fini leur collaboration dans des états différents. + +L'histoire présentée en figure \ref{enesmble2} ne nous permet pas de trancher. Par défaut l'approche est optimistes et nous considérons que cette histoire satisfait le critère de cohérence séquentielle puisque étant le critère le plus haut applicable à cette histoire. + +\subsubsection{Les critères de cohérences faibles} + +La cohérence séquentielle est le nom donné au critère qui définit qu'une histoire concurrente soit indiscernable de son équivalent non concurrent. C'est le critère de cohérence le plus fort, celui privilégier par les applications d'édition collaborative grand public. + +La cohérence séquentielle a était découverte au début de l'informatique distribuée par Lamport \cite{lamport_how_1979,lamport_interprocess_1986} lorsqu'il travaillait pour Intel sur les premiers processeurs multicœur. +À l'époque les processeurs atteignait une limite en termes de précision de gravure. Et est naturellement venu l'idée de mettre plusieurs cœurs dans une même puce afin de répartir la tâche et de gagner en performance. Il a fallu réfléchir au comportement qu'on attendait d'une telle architecture afin d'éviter au maximum les conflits et la perte de temps lié à la résolution de problèmes de synchronisation des cœurs entre eux. + +La cohérence séquentielle peut être découpée en 3 propriétés que sont : la validité, la localité d'état et la convergence. On dit que la cohérence séquentielle satisfait ces trois propriétés, on la considère ainsi comme étant un critère de cohérence fort. Les critères de cohérences ne satisfaisant qu'un seul ou deux de ces propriétés sont donc qualifiés de cohérence faible, proposant des compromis diminuant la cohérence d'une application, mais présentant des avantages sur l'efficacité algorithmique. + +\paragraph{La convergence} + +La convergence est la première propriété que nous allons définir. Elle est illustrée par la figure \ref{convergence}. + +\begin{figure}[!h] + \centering + \resizebox*{.4\textwidth}{!}{\input{schemas/convergence.tex}} + \caption{Exemple d'histoire convergente} + \label{convergence} +\end{figure} + +La convergence se concentre seulement sur l'état final de l'histoire concurrente sans jamais prendre en compte les opérations précédentes. Pour qu'une histoire satisfasse le critère de convergence, elle doit admettre un état unique justifiant les lectures finales d'un système. + +En d'autres termes, si tous les membres du réseau arrêtent d'écrire et réalisent en boucle sur une durée infinie des opérations de lecture. Alors toutes les opérations de lectures doivent fournir un résultat identique dépendant d'un seul et même état. + +Dans la figure \ref{convergence} on constate que les lectures finales ne prennent pas en compte les opérations précédentes. Ce qui se traduit du point de vue du nœud 0 par une non prise en compte de ses soumissions, et du point de vue du nœud 1 comme un retour en arrière de son état après la soumission d'un événement. Mais aucune opération de suppression n'a jamais était émise. +Ainsi il n'existe aucune linéarisation possible permettant de justifier cet état final. + +Si nous voulions le traduire de manière concrète à la problématique d'un éditeur collaboratif, cela reviendrait en un document qui se verrait modifier dans un premier temps, puis sur lequel ces mêmes modifications serait supprimées sans raison apparente pour l'utilisateur. Cela ne permet donc pas de garantir une cohérence du point de vue de l'expérience utilisateur, mais seulement une cohérence sur l'état final des données. + + +\paragraph{La Localité d'état} +Là où la convergence assure la cohérence des données à la fin de l'exécution, la localité d'état assure la cohérence du point de vue du nœud. + +On le formalise donc comme l'existence pour chaque nœud d'une linéarisation incluant l'ensemble des opérations de lecture de ce nœud ainsi qu'un sous-ensemble des écritures du système. + +\begin{figure}[!h] + \centering + \resizebox*{.4\textwidth}{!}{\input{schemas/localiteetat.tex}} + \caption{Exemple d'histoire respectant la localité d'état} + \label{le} +\end{figure} + +Dans le cas de la figure \ref{le} on observe bel et bien une histoire qui respecte la localité d'état. Les lectures du nœud 0 peuvent être linéarisées tel que $R/\{\emptyset\} \bullet I(1) \bullet R/\{1\}$. Il en est de même pour le nœud 1 via la linéarisation $R/\{\emptyset\} \bullet I(0) \bullet R/\{0\}$. + +Ce qui nous interpelle ici, c'est que nous avons omis les écritures locales à chaque nœud afin de préserver la cohérence des lectures. Dans la localité d'état, il est plus important que les observations de l'utilisateur soient cohérentes, plutôt que de conserver les actions réalisées par ce dernier. +Les informations peuvent très bien être divergente in fine puisque ce qui compte, c'est la cohérence de l'expérience et non pas celle du système. + +En appliquant le critère à notre problématique d'éditeur collaboratif. Cela reviendrait à un document qui aura toujours du sens du point de vue de l'utilisateur, mais risquant de diverger entre les différents nœuds. Créant ainsi une ramification des versions du document. On peut l'assimiler au fonctionnement d'un dépôt git mettant à jour seulement les fichiers n'ayant jamais était édité par l'utilisateur, s'affranchissant ainsi de tout conflit à régler qui viendrait perturber la cohérence locale. + +\paragraph{La Validité} + +La dernière propriété à être présentée est la Validité. Elle assure que les lectures finales résultent d'une linéarisation de l'ensemble des opérations d'écritures. + +\begin{figure}[!h] + \centering + \resizebox*{.4\textwidth}{!}{\input{schemas/validite.tex}} + \caption{Exemple d'histoire respectant la validité} + \label{validite} +\end{figure} + +Dans la figure \ref{validite} cela se traduit par la lecture $R/\{1\}$ linéarisable par $D/(1) \bullet I(1) \bullet R/\{1\}$ bien que cet ordre n'est pas cohérent au vu de la première lecture du nœud 1. En effet, elle force à croire que l'insertion est déjà prise en compte avant même que l'opération de suppression ne soit soumise. + +La validité ne peut donc pas permettre la préservation d'une cohérence locale ou convergente. Mais elle assure que le résultat est cohérent dépendamment des opérations d'écritures émises dans le système. + +Dans notre contexte imaginons que deux utilisateurs modifie la même partie du document en local. Si leurs travaux vise à être fusionnés, alors il risque d'y avoir deux fois la même ligne, ou bien un entrelacement des deux lignes. Mais en respectant la validité on assure qu'en aucun cas l'utilisateur se verra supprimer ou refuser son opération par l'algorithme. + +\subsection{Quelle direction pour notre sujet ?} + +Perrin \cite{perrin_concurrence_2017} propose une cartographie des différents critères de cohérences connus. +Elle prend la forme d'une carte en deux dimensions comportant 3 zones s'entrelaçant comme montré dans la figure \ref{perrin}. Chaque zone correspondant à une propriété définit plus haut. + +\begin{figure}[h!] + \centering + \resizebox{0.4\columnwidth}{!}{ + \includegraphics{images/carte_criteres.png} + } + \caption{Cartographie des critères de cohérences par Mathieu Perrin} + \label{perrin} +\end{figure} + +L'intersection de ces 3 zones correspond donc à la cohérence forte. Et le reste du schéma à des critères de cohérence faibles. + +Pour savoir où chercher le critère de cohérence nécessaire à la résolution de notre problématique, nous devons déterminer quelles sont les propriétés nécessaires à la réalisation d'un bon éditeur collaboratif. + +Ainsi la convergence semble être une propriété essentielle pour notre produit. En effet, on attend d'un bon éditeur de document qu'il nous permette de réaliser, une fois les sessions d'éditions terminées, un document unique et non pas plusieurs versions divergentes. + +Pour rester dans la cohérence faible, nous devons au choix respecter soit la validité, soit la localité d'état. + +Dans le premier cas, nous prenons parti de tolérer des remaniements de l'histoire lors des synchronisations provoquant le non-respect de la cohérence du document du point de vue de l'utilisateur. Cela risque de créer des insertions et suppressions arbitraires et des annulations d'opérations pourtant bien retourner à l'utilisateur. L'expérience semblera incohérente et illogique pour ce dernier. + +Dans le second on autorise le système à réaliser des opérations n'ayant jamais était émise ou omettre d'autres opérations afin de préserver la cohérence locale. Dégradant par la même occasion l'expérience de l'utilisateur en lui donnant une sensation de "retour en arrière" sur ses opérations. + +\subsection{Accepter de la non-convergence avec les CRDTs} + +Une autre solution est néanmoins possible, en utilisant un type de donnée particulier. En effet, il est possible d'accepter une non-convergence des états si le type de données que nous échangeons permet déjà d'assurer une convergence. C'est possible en utilisant des CRDTs que nous allons définir. + +Les CRDTs (Conflict-free Replicated Data Types) \cite{shapiro2011conflict} sont des structures de données conçues pour fonctionner efficacement dans des environnements distribués, où plusieurs répliques des données peuvent être modifiées simultanément. Ils garantissent la convergence des données répliquées sans nécessiter d'ordonnanceur intermédiaire. + +Le principe fondamental des CRDTs repose sur la notion d'opérations commutatives et associatives. En d'autres termes, les opérations sur les données répliquées peuvent être effectuées dans n'importe quel ordre sans entraîner de conflits ou de résultats incohérents. Cela permet aux applications utilisant des CRDTs de soumettre des opérations concurrentes sans jamais avoir à ne résoudre de conflit. + +Les CRDTs peuvent nous permettre dans notre cas, de s'affranchir du critère de convergence et ainsi privilégier la validité et la localité d'état qui sont les deux impactants l'expérience de l'utilisateur d'un point de vue local. + +\subsubsection{Quel est donc le critère le plus adapté ?} + +En étudiant la cartographie de Perrin (figure \ref{perrin}), il semble que les critères les plus pertinents sont la cohérence pipeline ($PC$), la cohérence causale ($CC$) et la cohérence causale forte ($SCC$). Au moment où j'écris ce rapport je n'ai pas encore déterminé lequel de ces 3 critères est le plus pertinent pour notre problématique. Néanmoins, nous pouvons présenter la cohérence pipeline qui est la base des deux autres critères, ce qui donne une idée d'à quoi un système respectant à la fois la Validité et la Localité d'état peut ressembler. + +\paragraph{Cohérence Pipeline} + +La cohérence pipeline fonctionne sur une logique du "premier arrivé premier servit" comme illustré dans la figure \ref{pipeline}. + +\begin{figure}[!h] + \centering + \resizebox*{.4\textwidth}{!}{\input{schemas/pipeline.tex}} + \caption{Exemple d'histoire respectant la cohérence pipeline} + \label{pipeline} +\end{figure} + +Ce critère ne garantit en effet pas la convergence, puisque les opérations peuvent arriver dans des ordres différents d'un nœud à l'autre. C'est problématique dans le cas d'un ensemble pouvant être soumis à des insertions et des suppressions comme ici. Mais dans une optique d'utilisation avec des CRDTs il n'y a pas nécessité à retirer des éléments. Notre ensemble stockera simplement un ensemble de CRDTs qui, peu importe leurs ordres d'arrivés reproduira systématiquement la même histoire. Ainsi nous aurions une exécution plus proche de celle de la figure \ref{pipeline_crdt}. + +\begin{figure}[!h] + \centering + \resizebox*{.5\textwidth}{!}{\input{schemas/pipeline_crdt.tex}} + \caption{Exemple d'histoire respectant la cohérence pipeline utilisant des CRDTs} + \label{pipeline_crdt} +\end{figure} + +\subsection{Appliquer un système reparti à un environnement malicieux} + +Une partie de mon travail à étais d'étudier le lien entre l'acceptation de critère de cohérences faibles et les risques de comportements malicieux. + +J'ai donc formulé à ce moment-là deux hypothèses possibles : + +Dans la première le fait de baisser le critère de cohérence ouvre la porte à plus de risques de comportement malicieux. Cette hypothèse semble être celle la plus étudiée. \cite{van_der_linde_practical_2020,kumar_fault-tolerant_2019} Mais les études sur le sujet semble concentrer les comportements à des implémentations satisfaisant les critères de cohérences et non pas au critère lui-même. Rendant ainsi difficile l'attribution de comportements malicieux à un critère de cohérence particulier. Il est compliqué de discerner si ces comportements ne relèvent pas simplement d'une erreur protocolaire dans l'implémentation. + +La deuxième hypothèse consiste à dire que puisque le critère de cohérence baisse, on accepte plus de situations qui serait considérés problématiques et malicieuse en temps normal. Ce qui rend par cette occasion un système à faible cohérence plus robuste. +Je n'ai pas trouvé de littérature appuyant particulièrement cette seconde hypothèse. + +\subsection{Les outils et pistes pour le développement d'un produit final} + +Le développement d'un éditeur collaboratif sans autorité de contrôle implique nécessairement la mise en place d'un réseau en pair à pair. Je me suis donc posé la question de la faisabilité réelle d'un réseau P2P à travers Internet dans le contexte d'une entreprise. + +Le frein principal est la présence de NAT du côté du fournisseur d'accès puis de l'entreprise. Dans des systèmes d'information complexe il peut même y avoir plusieurs profondeurs de NAT au sein d'une seule organisation. Le NAT (Network Address Translation) à pour but de faire une translation d'adresse entre l'adresse publique de l'entreprise, routable via Internet, avec l'adresse privé de la machine, routable seulement sur le réseau local de l'entreprise. +Cette couche rend impossible pour une personne extérieure au réseau de l'entreprise de contacter un client cacher derrière un NAT sans que celui-ci soit configurer à cet usage. + +Ce fonctionnement est particulièrement problématique dans le contexte d'une application en pair à pair. La solution qui fait néanmoins consensus est d'adopter la technique du hôle-punching. \cite{ford2005peer} +Le hôle-punching consiste en un détournement du fonctionnement du protocole UDP afin de réaliser une connexion en pair à pair. + +Pour ce faire nous avons besoin d'un serveur exposé sur Internet et connu des pairs. Lorsqu'un des nœuds source veut entrer en contact avec un nœud cible, il demande au serveur la mise en relation avec un autre membre du réseau. +Le serveur envoie donc l'adresse IP et le port du NAT derrière lequel se cache le nœud cible. + +Dans le même temps, le serveur prévient le nœud cible de l'arrivée du nœud source. Une fois que les deux nœuds possèdent mutuellement l'adresse de l'un et de l'autre. Ils initient chacun auprès de leurs NAT une connexion l'un vers l'autre. Le NAT du nœud source s'attend donc bien à recevoir un message du NAT du nœud cible et vice-verse. + +Cette technique nous permet donc d'envisager le fonctionnement d'un tel système en pair à pair dans un contexte réel d'entreprise. + +La seule limitation qui pourrait se retrouver en désaccord avec la politique zero-trust de parsec est la mise en place d'un serveur dit de "rendez-vous" qui devrait gérer un annuaire des adresses IP de chaque nœud du réseau. Mais ce sont les seules informations auquel le serveur à accès puisque le reste de l'échange se réalise directement en pair à pair. Le serveur Parsec possédant déjà l'information de l'adresse IP de par les logs d'accès au stockage de fichier, cette solution ne nécessite aucune information supplémentaire de la part du serveur Parsec. Elle reste donc compatible avec les primitives de sécurités et de confidentialités liées à Parsec. \ No newline at end of file