hard push
This commit is contained in:
amaury
parent
e51d7de452
commit
ab70a09cbf
32
.devcontainer/devcontainer.json
Normal file
32
.devcontainer/devcontainer.json
Normal file
@ -0,0 +1,32 @@
|
||||
// Add you DevContainer configuration in this file
|
||||
// See: https://containers.dev/ for the "official" DevContainer specifications
|
||||
{
|
||||
"name": "latex-default", //Add the name your DevContainer Here,
|
||||
"image": "pandoc/latex:latest-ubuntu", //Add the name of your Docker image here. See: https://hub.docker.com for available containers
|
||||
"containerEnv": { //Add your build arguments here
|
||||
"DEBIAN_FRONTEND": "noninteractive"
|
||||
},
|
||||
"runArgs": [], //Add you docker run arguments here
|
||||
"updateContentCommand": ".devcontainer/install-tools.sh", //Path to the installation script run inside the DevContainer
|
||||
// "customizations": {
|
||||
// //Add your customizations here
|
||||
// },
|
||||
// "forwardPorts": [], //Add your port forwarding from inside/oustide here
|
||||
"workspaceMount": "source=${localWorkspaceFolder},target=/workspaces/containers,type=bind", //Add your local mounting inside the DevContainer here
|
||||
"workspaceFolder": "/workspaces/containers", //Add your workspace folder here
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
"extensions": [
|
||||
"james-yu.latex-workshop",
|
||||
"eamodio.gitlens",
|
||||
"jenselme.grammalecte",
|
||||
],
|
||||
"settings": {
|
||||
"grammalecte.allowedExtension": ".md,.rst,.adoc,.asciidoc,.creole,.t2t,.tex",
|
||||
}
|
||||
}
|
||||
},
|
||||
"features": {
|
||||
"ghcr.io/devcontainers/features/git:1": {},
|
||||
}
|
||||
}
|
||||
15
.devcontainer/install-tools.sh
Executable file
15
.devcontainer/install-tools.sh
Executable file
@ -0,0 +1,15 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Update package lists
|
||||
apt update
|
||||
|
||||
# Install Git
|
||||
# apt install -y git
|
||||
tlmgr install preprint
|
||||
|
||||
# installation de grammalecte
|
||||
apt install python3 unzip -y
|
||||
mkdir /root/.grammalecte
|
||||
cd /root/.grammalecte
|
||||
wget https://grammalecte.net/zip/Grammalecte-fr-v2.1.1.zip
|
||||
unzip Grammalecte-fr-v2.1.1.zip
|
||||
@ -0,0 +1,15 @@
|
||||
\begin{frame}
|
||||
\frametitle{My work}
|
||||
|
||||
\begin{block}{What's next ?}
|
||||
\begin{itemize}
|
||||
\item Study and formalize some "in-prod" algorithms using weak consistency in byzantine contexts.
|
||||
\item Continue the collaboration with Parsec:
|
||||
\begin{itemize}
|
||||
\item formalize a list of properties
|
||||
\end{itemize}
|
||||
\item identifies which applications are suitable for each class of weak consistency.
|
||||
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@ -0,0 +1,14 @@
|
||||
\begin{frame}
|
||||
\frametitle{The Byzantine context associated with the weak consistency}
|
||||
|
||||
\begin{block}{Some questions about:}
|
||||
\begin{itemize}
|
||||
\item is the weak consistency introduces more or less possibility of malicious behaviors.
|
||||
\item is the cost to make a system Byzantine Fault Tolerant is higher or lower with weak consistency.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
|
||||
The state of the art is poor about these questions and few formalized algorithms are available.
|
||||
|
||||
|
||||
\end{frame}
|
||||
122
docs/presentations/LIS/Anglais_avril_2024/consistency/faible.tex
Normal file
122
docs/presentations/LIS/Anglais_avril_2024/consistency/faible.tex
Normal file
@ -0,0 +1,122 @@
|
||||
\begin{frame}
|
||||
\frametitle{The models of consistency}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.6\textwidth}
|
||||
\footnote{Perrin, \emph{Concurrence et cohérence dans les systèmes répartis}, 2017}
|
||||
\resizebox{\columnwidth}{!}{
|
||||
\includegraphics{images/carte_criteres.png}
|
||||
}
|
||||
|
||||
\column{0.4\columnwidth}
|
||||
\begin{block}{Les classes de cohérences}
|
||||
2 big family :
|
||||
\begin{itemize}
|
||||
\item Strong Consistency
|
||||
\item Weak Consistency :
|
||||
\begin{itemize}
|
||||
\item Eventual Consistency (EC)
|
||||
\item State Locality (SL)
|
||||
\item Validity (V)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Eventual Consistency (EC)}
|
||||
|
||||
\begin{block}{Definition}
|
||||
There exists a set of cofinite operations where each one must be justified with the same state.
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/convergence_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(1,2)^\omega, r/(1,2)^\omega\}$ \newline
|
||||
$\delta = ((1,2), \emptyset)$ is a valid state justifying $E'$.
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/convergence_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(1,2)^\omega, r/(2,1)^\omega\}$. \newline
|
||||
There exists no state able to justify $E'$ because the two infinite reads are not consistent.
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{State Locality}
|
||||
|
||||
\begin{block}{Definition}
|
||||
For all $p$, there exists one linearization that includes all the read operations of $p$. According to the local order of these reads. \\
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/localiteetat_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
\begin{math}
|
||||
\begin{array}{l}
|
||||
\textcolor{blue}{C_{p_0} = \{r/(0,0), r/(0,2)^\omega, w(2)\}}, \\
|
||||
\textcolor{red}{C_{p_1} = \{r/(0,0), r/(0,1)^\omega, w(1)\}}, \\
|
||||
\textcolor{blue}{r/(0,0) \bullet w(2) \bullet r/(0,2)^\omega} \\
|
||||
\textcolor{red}{r/(0,0) \bullet w(1) \bullet r/(0,1)^\omega} \\
|
||||
\end{array}
|
||||
\end{math}
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/localiteetat_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E'_{p_0} = \{r/(0,0), r/(2,1)^\omega\},$ \newline
|
||||
$r/(0,0) \bullet w(2) \bullet w(1) \bullet r/(2,1)^\omega$ \newline
|
||||
$E'_{p_1} = \{r/(0,1), r/(2,1)^\omega\}$. \newline
|
||||
There exists no linearization of $p_1$ satisfying the definition of state locality
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Validity (V)}
|
||||
|
||||
\begin{block}{Definition}
|
||||
There exists a cofinite set of operations such as each of them must be justified by a linearization of all the write operations.
|
||||
\end{block}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=green!50!black]
|
||||
\input{schemas/validite_hc_1}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
\begin{math}
|
||||
\begin{array}{ll}
|
||||
E' = & \{r/(2,1)^\omega, r/(1,2)^\omega\} \\
|
||||
& w(2) \bullet w(1) \bullet \textcolor{red}{r/(2,1)^\omega} \\
|
||||
& w(1) \bullet w(2) \bullet \textcolor{red}{r/(1,2)^\omega} \\
|
||||
\end{array}
|
||||
\end{math}
|
||||
\end{columns}
|
||||
|
||||
\begin{columns}
|
||||
\column{0.4\columnwidth}
|
||||
\begin{tcolorbox}[colframe=red!50!black]
|
||||
\input{schemas/validite_hc_2}
|
||||
\end{tcolorbox}
|
||||
\column{0.5\columnwidth}
|
||||
$E' = \{r/(0,1)^\omega, r/(1,2)^\omega\}$. \\
|
||||
There is no linearization of the write operation able to justify $r/(0,1)^\omega$.
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
@ -0,0 +1,45 @@
|
||||
\begin{frame}
|
||||
\frametitle{Safety}
|
||||
\begin{block}{Definition}
|
||||
Each \textbf{read} operation made in the same \textbf{non-competitor} context provides the same result.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_surete_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Regularity}
|
||||
\begin{block}{Definition}
|
||||
An \textbf{reading operation concurrent with a writing operation} must provide the value \textbf{before or after the write}.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_regularite_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomicity}
|
||||
\begin{block}{Definition}
|
||||
If \textbf{two readings are non-competitor}, the second one must provide a value \textbf{at least as recent as} the previous one.
|
||||
\end{block}
|
||||
\begin{figure}
|
||||
\input{schemas/linearisation_atomicite_hc}
|
||||
\end{figure}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Atomic Consistency ($C_\top$)}
|
||||
|
||||
\begin{block}{Définition}
|
||||
Atomic consistency is the stronger consistency class.
|
||||
\begin{itemize}
|
||||
\item Provide an awful interactivity.
|
||||
\item Need a strong synchronization between each operation.
|
||||
\begin{itemize}
|
||||
\item Each read or write operation locks the others and needs to wait for the release from the previous one.
|
||||
\end{itemize}
|
||||
\item He's used as a reference for the other consistency class.
|
||||
\end{itemize}
|
||||
\end{block}
|
||||
\end{frame}
|
||||
@ -0,0 +1,8 @@
|
||||
\subsection{Strong consistency}
|
||||
\include{consistency/forte.tex}
|
||||
|
||||
\subsection{The compromises of the strong consistency}
|
||||
\include{consistency/faible.tex}
|
||||
|
||||
\subsection{In a malicious context ?}
|
||||
\include{consistency/byzantin.tex}
|
||||
@ -0,0 +1,32 @@
|
||||
\begin{frame}
|
||||
\frametitle{A distributed system}
|
||||
|
||||
\begin{block}{Definition}
|
||||
A distributed system is a group of \textbf{actors} able to communicate \textbf{each-other} working together to \textbf{complete a common task}.
|
||||
\end{block}
|
||||
|
||||
% Schéma d'un système distribué
|
||||
|
||||
The system we consider in this presentation is a \textbf{asynchronous message-passing} system.
|
||||
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{A distributed system is a living system}
|
||||
|
||||
A distributed system changes over time.
|
||||
|
||||
There are some ways to study these changes :
|
||||
\begin{itemize}
|
||||
\item focus on the \textbf{churn} (node addition and removal).
|
||||
\item focus on the \textbf{messages}.
|
||||
\item focus on the \textbf{connectedness}.
|
||||
\item focus on the \textbf{states}. $\Leftarrow$
|
||||
\item probably more... ?
|
||||
\end{itemize}
|
||||
|
||||
The study of the state changes is also called the study of \textbf{consistency}.
|
||||
|
||||
\textbf{A small exemple}: A peer-to-peer discussion
|
||||
|
||||
\end{frame}
|
||||
@ -0,0 +1,2 @@
|
||||
\subsection{Définition}
|
||||
\include{distr_sys/bases}
|
||||
BIN
docs/presentations/LIS/Anglais_avril_2024/images/carte_criteres.png
Executable file
BIN
docs/presentations/LIS/Anglais_avril_2024/images/carte_criteres.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
@ -0,0 +1,4 @@
|
||||
|
||||
|
||||
\subsection{My Thesis}
|
||||
\include{intro/suite.tex}
|
||||
17
docs/presentations/LIS/Anglais_avril_2024/intro/suite.tex
Normal file
17
docs/presentations/LIS/Anglais_avril_2024/intro/suite.tex
Normal file
@ -0,0 +1,17 @@
|
||||
\begin{frame}
|
||||
\frametitle{My Thesis}
|
||||
|
||||
\begin{itemize}
|
||||
\item Collaboration between Parsec and LIS-LAB
|
||||
\begin{itemize}
|
||||
\item Parsec is a for-profit organization working on an open-source software named Parsec
|
||||
\item It's a software architecture for file sharing with E2EE in a zero-trust approach
|
||||
\end{itemize}
|
||||
\item Parsec wants to add Collaborative Editing on their products:
|
||||
\begin{itemize}
|
||||
\item With a zero-trust approach (so probably decentralized)
|
||||
\item With a high availability and low latency approach
|
||||
\end{itemize}
|
||||
\item Subject is \textit{Weak Consistency Byzantine Fault Tolerent}
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
60
docs/presentations/LIS/Anglais_avril_2024/main.tex
Executable file
60
docs/presentations/LIS/Anglais_avril_2024/main.tex
Executable file
@ -0,0 +1,60 @@
|
||||
\documentclass{beamer}
|
||||
\usetheme{Boadilla}
|
||||
\usecolortheme{orchid}
|
||||
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage[french]{babel}
|
||||
\usepackage{stackengine}
|
||||
|
||||
\addtobeamertemplate{navigation symbols}{}{%
|
||||
\usebeamerfont{footline}%
|
||||
\usebeamercolor[fg]{footline}%
|
||||
\hspace{1em}%
|
||||
\insertframenumber/\inserttotalframenumber
|
||||
}
|
||||
\usepackage{ulem}
|
||||
\usepackage{tkz-tab}
|
||||
\setbeamertemplate{blocks}[rounded]%
|
||||
[shadow=true]
|
||||
\AtBeginSection{%
|
||||
\begin{frame}
|
||||
\tableofcontents[sections=\value{section}]
|
||||
\end{frame}
|
||||
}
|
||||
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{positioning}
|
||||
\usetikzlibrary{calc}
|
||||
\usetikzlibrary{arrows.meta}
|
||||
|
||||
\usepackage{tcolorbox}
|
||||
|
||||
\title[bwconsistency]{Weak consistency application to zero-trust cloud}
|
||||
\subtitle{English Courses}
|
||||
\author[JOLY Amaury]{JOLY Amaury\\ \textbf{Encadrants :} GODARD Emmanuel, TRAVERS Corentin }
|
||||
% \\[2ex] \includegraphics[scale=0.1]{./img/amu.png}
|
||||
\institute[LIS, Scille]{LIS-LAB, Scille}
|
||||
\date{04 April 2024}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\maketitle
|
||||
|
||||
\begin{frame}{Summary}
|
||||
\tableofcontents
|
||||
\end{frame}
|
||||
|
||||
\section{Introduction}
|
||||
\input{intro/index.tex}
|
||||
|
||||
\section{Distributed systems and consistency}
|
||||
\input{distr_sys/index.tex}
|
||||
|
||||
\section{The compromises of consistency}
|
||||
\input{consistency/index.tex}
|
||||
|
||||
\section{What's next ?}
|
||||
\input{conclusion/index.tex}
|
||||
|
||||
\end{document}
|
||||
BIN
docs/presentations/LIS/Anglais_avril_2024/schemas/ccv_hc_1.png
Executable file
BIN
docs/presentations/LIS/Anglais_avril_2024/schemas/ccv_hc_1.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_1.tex
Executable file
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_1.tex
Executable file
@ -0,0 +1,41 @@
|
||||
\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) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$I(a)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,1)$};
|
||||
\node[roundnode] (14) [right=35pt of 13] {};
|
||||
\node[above] at (14.north) {$r/(1,2)^\omega$};
|
||||
|
||||
\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) {$w(2)$};
|
||||
\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,2)$};
|
||||
\node[roundnode] (24) [right=35pt of 23] {};
|
||||
\node[below] at (24.south) {$r/(1,2)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\draw[arrow] (23) -- (24);
|
||||
|
||||
\draw (24) -- (14);
|
||||
|
||||
\draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -2.9);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_2.tex
Executable file
41
docs/presentations/LIS/Anglais_avril_2024/schemas/convergence_hc_2.tex
Executable file
@ -0,0 +1,41 @@
|
||||
\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) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$I(a)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,1)$};
|
||||
\node[roundnode] (14) [right=35pt of 13] {};
|
||||
\node[above] at (14.north) {$r/(1,2)^\omega$};
|
||||
|
||||
\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) {$w(2)$};
|
||||
\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,2)$};
|
||||
\node[roundnode] (24) [right=35pt of 23] {};
|
||||
\node[below] at (24.south) {$r/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\draw[arrow] (23) -- (24);
|
||||
|
||||
\draw (24) -- (14);
|
||||
|
||||
\draw[dashed] ($(14)!0.5!(13) + (0,1)$) -- ++(0, -2.9);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red}{$r/(1)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red}{$r/(1)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@ -0,0 +1,26 @@
|
||||
\resizebox{\columnwidth}{!}{%
|
||||
\begin{tikzpicture}[
|
||||
roundedrectangle/.style={draw, rounded corners, rectangle, minimum height=10pt, minimum width=20pt},
|
||||
invisible/.style={draw=none, fill=none},
|
||||
]
|
||||
|
||||
\node[invisible] (10) {};
|
||||
\node[roundedrectangle, minimum width=150pt] (11) [right=100pt of 10] {$w_x(1)$};
|
||||
\node[invisible] (12) [right=100pt of 11] {};
|
||||
|
||||
\node[invisible] (20) [below=15pt of 10] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (21) [right=25pt of 20] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (22) [right=75pt of 21] {\textcolor{blue}{$r/(0)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (23) [right=75pt of 22] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (24) [below=15pt of 12] {};
|
||||
|
||||
\node[invisible] (30) [below=15pt of 20] {};
|
||||
\node[roundedrectangle, minimum width=50pt] (31) [right=125pt of 30] {\textcolor{red!50!blue}{$r/(27)$}};
|
||||
\node[roundedrectangle, minimum width=50pt] (32) [right=40pt of 31] {\textcolor{red}{$r/(1)$}};
|
||||
\node[invisible] (33) [below=15pt of 24] {};
|
||||
|
||||
\draw (10) -- (11) -- (12);
|
||||
\draw (20) -- (21) -- (22) -- (23) -- (24);
|
||||
\draw (30) -- (31) -- (32) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
34
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_1.tex
Executable file
34
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_1.tex
Executable file
@ -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, draw=red, fill=red] (11) {};
|
||||
\node[left] at (11.west) {$p_0$};
|
||||
\node[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode, draw=blue, fill=blue] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(0,0)$};
|
||||
\node[roundnode, draw=blue, fill=blue] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, draw=blue, fill=blue] (21) [below=10pt of 11] {};
|
||||
\node[left] at (21.west) {$p_1$};
|
||||
\node[below] at (21.south) {$w(2)$};
|
||||
\node[roundnode, draw=red, fill=red] (22) [right=of 21] {};
|
||||
\node[below] at (22.south) {$r/(0,0)$};
|
||||
\node[roundnode, draw=red, fill=red] (23) [right=of 22] {};
|
||||
\node[below] at (23.south) {$r/(0,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
|
||||
\draw[message] (11) -- ($(22)!0.5!(23)$);
|
||||
\draw[message] (21) -- ($(12)!0.5!(13)$);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
32
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_2.tex
Executable file
32
docs/presentations/LIS/Anglais_avril_2024/schemas/localiteetat_hc_2.tex
Executable file
@ -0,0 +1,32 @@
|
||||
\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) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(0,0)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,2)^\omega$};
|
||||
|
||||
\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) {$w(2)$};
|
||||
\node[roundnode] (22) [right=of 21] {};
|
||||
\node[below] at (22.south) {$r/(0,1)$};
|
||||
\node[roundnode] (23) [right=of 22] {};
|
||||
\node[below] at (23.south) {$r/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
|
||||
\end{tikzpicture}
|
||||
}
|
||||
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_1.tex
Executable file
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_1.tex
Executable file
@ -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) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(0,1)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(2,1)^\omega$};
|
||||
|
||||
\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) {$w(2)$};
|
||||
\node[roundnode] (22) [right=of 21] {};
|
||||
\node[below] at (22.south) {$r/(0,2)$};
|
||||
\node[roundnode] (23) [right=of 22] {};
|
||||
\node[below] at (23.south) {$r/(1,2)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_2.tex
Executable file
31
docs/presentations/LIS/Anglais_avril_2024/schemas/validite_hc_2.tex
Executable file
@ -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) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(0,1)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(0,1)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=10ptof 11] {};
|
||||
\node[left] at (21.west) {$p_1$};
|
||||
\node[below] at (21.south) {$w(2)$};
|
||||
\node[roundnode] (22) [right=of 21] {};
|
||||
\node[below] at (22.south) {$r/(0,2)$};
|
||||
\node[roundnode] (23) [right=of 22] {};
|
||||
\node[below] at (23.south) {$r/(1,2)^\omega$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
\draw[arrow] (22) -- (23);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
42
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_1.tex
Executable file
42
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_1.tex
Executable file
@ -0,0 +1,42 @@
|
||||
\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, color=red] (11) {};
|
||||
\node[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode, color=red!50] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(0,1)$};
|
||||
\node[roundnode, color=red!25] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(3,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, color=green!75!black] (21) [below=20pt of 11] {};
|
||||
\node[left] at (21.west) {$r/(3,1)$};
|
||||
\node[roundnode, color=green!95!black] (22) [right=of 21] {};
|
||||
\node[right] at (22.east) {$w(2)$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
|
||||
\node[roundnode, color=blue] (31) [below=20pt of 21] {};
|
||||
\node[below] at (31.south) {$w(3)$};
|
||||
\node[roundnode, color=blue!50] (32) [right=of 31] {};
|
||||
\node[below] at (32.south) {$r/(3,1)$};
|
||||
\node[roundnode, color=blue!25] (33) [right=of 32] {};
|
||||
\node[below] at (33.south) {$r/(3,2)^\omega$};
|
||||
|
||||
\draw[arrow] (31) -- (32);
|
||||
\draw[arrow] (32) -- (33);
|
||||
|
||||
\draw[message] (11) -- (21);
|
||||
\draw[message] (31) -- (21);
|
||||
\draw[message] (21) -- (32);
|
||||
\draw[message] (22) -- (13);
|
||||
\draw[message] (22) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
29
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_2.tex
Executable file
29
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_2.tex
Executable file
@ -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[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(2,1)$};
|
||||
\node[roundnode] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(2,1)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode] (21) [below=20pt of 11] {};
|
||||
\node[left] at (21.west) {$r/(0,1)$};
|
||||
\node[roundnode] (22) [right=of 21] {};
|
||||
\node[right] at (22.east) {$w(2)$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
|
||||
\draw[message] (11) -- (21);
|
||||
\draw[message] (22) -- (12);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
41
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_3.tex
Executable file
41
docs/presentations/LIS/Anglais_avril_2024/schemas/wcc_hc_3.tex
Executable file
@ -0,0 +1,41 @@
|
||||
\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, color=red] (11) {};
|
||||
\node[above] at (11.north) {$w(1)$};
|
||||
\node[roundnode, color=red!50] (12) [right=of 11] {};
|
||||
\node[above] at (12.north) {$r/(3,1)$};
|
||||
\node[roundnode, color=red!25] (13) [right=of 12] {};
|
||||
\node[above] at (13.north) {$r/(1,2)^\omega$};
|
||||
|
||||
\draw[arrow] (11) -- (12);
|
||||
\draw[arrow] (12) -- (13);
|
||||
|
||||
\node[roundnode, color=green!75!black] (21) [below=20pt of 11] {};
|
||||
\node[left] at (21.west) {$r/(0,0)$};
|
||||
\node[roundnode, color=green!95!black] (22) [right=of 21] {};
|
||||
\node[right] at (22.east) {$w(2)$};
|
||||
|
||||
\draw[arrow] (21) -- (22);
|
||||
|
||||
\node[roundnode, color=blue] (31) [below=20pt of 21] {};
|
||||
\node[below] at (31.south) {$w(3)$};
|
||||
\node[roundnode, color=blue!50] (32) [right=of 31] {};
|
||||
\node[below] at (32.south) {$r/(1,3)$};
|
||||
\node[roundnode, color=blue!25] (33) [right=of 32] {};
|
||||
\node[below] at (33.south) {$r/(3,2)^\omega$};
|
||||
|
||||
\draw[arrow] (31) -- (32);
|
||||
\draw[arrow] (32) -- (33);
|
||||
|
||||
\draw[message] (11) -- (31);
|
||||
\draw[message] (31) -- (12);
|
||||
\draw[message] (22) -- (13);
|
||||
\draw[message] (22) -- (33);
|
||||
\end{tikzpicture}
|
||||
}
|
||||
@ -27,7 +27,7 @@
|
||||
\usetikzlibrary{positioning}
|
||||
\usetikzlibrary{calc}
|
||||
\usetikzlibrary{arrows.meta}
|
||||
|
||||
&
|
||||
\usepackage{tcolorbox}
|
||||
|
||||
\title[bwconsistency]{Étude de la cohérence dans les systèmes distribués}
|
||||
|
||||
45
docs/rapport/CRDT/intro/index.tex
Normal file
45
docs/rapport/CRDT/intro/index.tex
Normal file
@ -0,0 +1,45 @@
|
||||
Les CRDT sont des types de données qui supportent de manière intrinsèque les critères de convergence (\textit{Strong Eventual Consistency}) et de cohérence pipeline (qui est un compromis entre la validité et la localité d’état).
|
||||
|
||||
Pour y parvenir, un type de donnée dit CRDT doit proposer une bibliothèque d’opérations commutatives entre elles. Ainsi, pour deux suites d’opérations $S$ et $S'$, soit $L$ l’ensemble contenant tous les termes de $S$ et $L'$ l’ensemble contenant tous les termes de $S'$. Si $L$ et $L'$ sont indiscernables, alors le résultat de $S$ et $S'$ l’est aussi. \cite{defago_conflict-free_2011}
|
||||
|
||||
Ces types de données présentent un très grand intérêt pour le problème de l’édition collaborative. \cite{preguica_commutative_2009, noauthor_yjsyjs_2023} En effet, elles permettent de mettre en place des approches qui sont dites "local-first". C’est-à-dire de proposer une architecture où les modifications sont dans un premier temps appliquées localement au client, pour ensuite être à termes fusionnés, sans avoir à gérer d’hypothétiques conflits (puisque le type de donnée ne le permet pas).
|
||||
|
||||
\subsection{Présentation des familles de CRDT}
|
||||
|
||||
Un type de donnée est dit CRDT s'il respecte les propriétés de commutativité et d’idempotence. Nous allons aborder deux grandes implémentations de CRDT : l'implémentation sous forme d'arbres binaires et celle sous forme de graphe orienté acyclique (DAG).
|
||||
|
||||
L'approche en DAG \cite{jacob_analysis_2021,almeida_blocklace_2024,kleppmann_making_2022} consiste à représenter les états via les noeuds du graphe et les opérations via les arcs. Il y a donc un état initial commun à l'ensemble des membres du système du quel part entre $1$ et $n$ opérations, chaque opération donnant sur un état. Avec $n$ étant le nombre d'acteur du système. Le prérequis de la modélisation en DAG est la présence d'un ordre total entre deux opérations émise par le même acteur, et le respect de cet ordre dans l'ordre de réception de tous les acteurs. Ne pas respecter cet ordre constituerait une violation du protocole et est appelé dans la littérature "une équivocation".
|
||||
|
||||
L'approche en arbre binaire \cite{weiss_logoot-undo_2012,nicolaescu_near_2016} ne se concentre pas sur l'ordre d'émission des opérations, mais sur l'ordre applicatif des opérations. Les noeuds de l'arbre deviennent donc des identifiants d'opérations, et la position d'un noeud dans l'arbre permet de déterminer son ordre d'application par rapport aux autres. L'approche en arbre apporte donc une notion d'identifiant unique possédant la propriété d'être comparables les uns aux autres, et pouvant toujours proposer une valeur entre deux bornes quelconques. Néanmoins ici l'information d'ordre partiel des opérations est perdue.
|
||||
|
||||
La deuxième approche est issue d'une tentative de résolution du problème de l'édition collaborative via des CRDT. Et c'est une solution qui permet de rendre des notions non commutatives (comme l'intention de l'utilisateur dans une opération d'insertion) commutatives.
|
||||
|
||||
\subsection{Différences de complexité}
|
||||
|
||||
\subsubsection{Résolution de conflits}
|
||||
|
||||
Les conflits n'existent pas sur les approches en DAG. En effet, les opérations sont toujours commutatives entre elles. Néanmoins pour considérer la perte de message, certaines implémentations utilisent une approche "d'arbre de hachage" pour garantir l'intégrité du DAG. Et c'est dans la gestion de cet arbre de hachage que des conflits peuvent apparaître. Ainsi au moment où N noeuds sont fusionnés par un acteur, le noeud issue de cette fusion aura pour signature une concaténation des signatures des noeuds fusionnés. Or le choix de l'ordre de fusion des noeuds et arbitraire. L'acteur ayant créé le noeud de fusion va donc réaliser un choix d'ordre de concaténation arbitraire. Et les autres acteurs devront vérifier toutes les combinaisons des noeuds "feuilles" possibles pour vérifier le choix de l'acteur initial. Ce qui fait de cette opération une opération en $O(n!)$ où $n$ est le nombre de noeuds feuilles.
|
||||
|
||||
Pour ce qui est des implémentations en arbre binaire, même sans considérer le problème de perte de message, il est possible de rencontrer des conflits. Si deux acteurs insèrent un noeud à la même position, alors il y a conflit. Ces implémentations utilisent le même mécanisme pour résoudre ce problème qui est l'usage d'un identifiant d'acteur. Chaque acteur est donc identifié par un identifiant unique, comparable avec les autres. Et cet identifiant est utilisé pour déterminer l'ordre entre les opérations en conflits. Puisque un acteur ne peut pas produire deux opérations en même temps (si nous considérons tous les acteurs honnêtes), il n'y a pas de conflit insolvable. Cela vient rajouter une nouvelle contrainte sur notre modèle qui est la nécessité d'avoir un identifiant attribué à chaque acteur. Mais cela permet de résoudre le problème de conflit en temps constant $O(1)$.
|
||||
|
||||
\subsection{Tolérence aux byzantins}
|
||||
|
||||
\subsubsection{Equivocation}
|
||||
|
||||
Une forme de comportement byzantin possible avec l'usage des CRDT est l'équivocation. Elle consiste en une violation de la propriété obligeant chaque acteur à soumettre ses opérations dans un ordre total (les unes après les autres) et de faire en sorte que cet ordre soit identique pour l'ensemble des autres acteurs du réseau.
|
||||
|
||||
Ici nous considérons le scénario de la double dépense lorsque nous parlerons d'équivocation. Un acteur émet deux opérations en même temps, et les envoie à deux ensemble d'acteurs distincts. Si le protocole ne propose pas de mécanisme de gossiping alors l'équivocation peut ne jamais être détectée et donc casser la propriété de convergence inhérente aux CRDT.
|
||||
|
||||
Dans le cas où un mécanisme de gossiping est mis en place, alors l'équivocation peut être détectée. Dans ce cas le système doit préserver l'intégralité des équivocations, puisque les CRDTs ne permettent pas la suppression d'opérations (la propriété "grow only").
|
||||
|
||||
A savoir qu'il existe implémentation des CRDT permettant de préserver au plus une opération équivoqué. Mais ce comportement est possible puisque l'implémentation en question se place dans un modèle synchrone, et permet au système d'ignorer des opérations (ce qui serait impossible dans un modèle asynchrone).
|
||||
|
||||
Une autre solution pour mitiger (mais pas résoudre) le problème de l'équivocation est de mettre en place un système de contrôle de l'intégrité du graphe. Cela revient en réalité à avoir un système de gossiping embarqué dans l'action d'émission de l'opération. Ainsi quand un acteur veut soumettre son opération, il y attache une information sur l'état du graphe (par exemple un hash de l'ensemble des noeuds) ce qui permet aux acteurs recevant l'opération de vérifier si l'état du graphe de l'émetteur est le même que le leur. Si ce n'est pas le cas alors cela signifie qu'ils n'ont pas reçu le même ensemble d'opérations, il est alors possible pour les acteurs de détecter les noeuds manquants par des techniques de comparaison de graphe. L'avantage de cette méthode est qu'elle ne nécessite pas l'augmentation du nombre de message échangé comme le ferait un système de gossiping. Néanmoins elle ne permet pas d'assurer la détection de l'équivocation. En effet, si l'équivocation est sur la dernière opération soumise dans le système alors il n'y aura aucun moyen de la détecter et les graphes resteront divergents.
|
||||
|
||||
Il est bon de noter que la détection (puis la résolution) de l'équivocation semble n'être possible que sur les implémentations en DAG. En effet, si il y a équivocation sur une opération dans un arbre binaire, on ne peut pas garder l'ensemble des opérations équivoqué. Cela casserait le caractère convergent de l'arbre puisque dans ce cas il serait possible d'avoir deux opérations avec le même emplacement dans l'arbre, et le même identifiant d'acteur. Il ne serait donc plus possible de choisir de manière déterministe l'ordre d'application des opérations. Une solution serait une approche synchrone comme il est possible de le faire dans un DAG et qui permettrait de préserver au plus une opération. Mais aucune implémentation n'a été proposée dans ce sens, et cela semble être compliqué d'appliquer cette solution sans la notion d'ordre partiel (que ne permet pas l'approche en arbre).
|
||||
|
||||
\section{Extension des CRDTs}
|
||||
|
||||
Les CRDTs, de par leur aspect commutatif, ne peuvent pas définir de notion d'état interdit. Tout état possible du système doit être atteignable. Ceci limite grandement les possibilités applicatives de ce type de donnée. En effet, prenons comme exemple un problème applicatif d'échange de jetons. Chaque acteur possède une quantité de jetons. Alors une propriété de ce système serait que les états possibles soient seulement ceux où l'intégralité des acteurs possèdent une quantité de jetons positive. Or un acteur peut très bien dépenser plus de jetons qu'il n'en possédait au départ si il en a reçu entre-temps. Mais cette suite d'opération ne serait pas commutative puisque suivant l'ordre d'application des opérations on pourrait avoir un acteur avec un solde négatif.
|
||||
|
||||
Ce problème peut être réglé à travers l'ajout d'une surcouche aux CRDTs, nommé PCDO (Process-Commutative Distributed Objects). \cite{frey_process-commutative_2023} Cette surcouche vient en réalité créer de l'intéraction entre un ensemble d'opérations commutatives et des ensembles d'opérations non commutatives. L'ensemble d'opération commutatives est alors un ensemble d'opérations utilisable par l'intégralité des acteurs quand ils le souhaitent. Leur application ne permet pas de faire entrer le système dans un état illégal. Chaque acteur possède ensuite ses propres opérations qui, elles, ne sont pas commutatives entre elles, et qu'il est le seul à pouvoir invoquer. Si il n'y a pas d'équivocation alors ces opérations non commutatives sont ordonnées suivant un ordre total (puisque qu'un acteur ne peut pas émettre deux opérations en même temps). Ainsi il est facile pour l'ensemble du système de se rendre compte lorsqu'un utilisateur essaie d'entrer dans un état illégal et donc de ne pas considérer les opérations associées.
|
||||
34
docs/rapport/CRDT/main.tex
Normal file
34
docs/rapport/CRDT/main.tex
Normal file
@ -0,0 +1,34 @@
|
||||
\documentclass{article}
|
||||
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage[utf8]{inputenc}
|
||||
\usepackage{csquotes}
|
||||
\usepackage[french]{babel}
|
||||
\usepackage[affil-it]{authblk}
|
||||
\usepackage{fullpage}
|
||||
|
||||
\usepackage{biblatex}
|
||||
|
||||
\addbibresource{sources.bib}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\title{??? Conflict Free Replicated Data Types ???}
|
||||
\author{JOLY Amaury \\ \textbf{Encadrants :} GODARD Emmanuel, TRAVERS Corentin}
|
||||
\affil{Aix-Marseille Université, Scille}
|
||||
\date{\today}
|
||||
|
||||
\begin{titlepage}
|
||||
\maketitle
|
||||
\end{titlepage}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
\subsection{Définition d'un CRDT}
|
||||
\input{intro/index.tex}
|
||||
|
||||
\printbibliography
|
||||
|
||||
|
||||
\end{document}
|
||||
549
docs/rapport/CRDT/sources.bib
Normal file
549
docs/rapport/CRDT/sources.bib
Normal file
@ -0,0 +1,549 @@
|
||||
|
||||
@misc{weiss_logoot-undo_2012,
|
||||
title = {Logoot-{Undo} {Distributed} {Collaborative} {Editing} {System}},
|
||||
author = {Weiss, Stéphane and Urso, Pascal and Molli, Pascal},
|
||||
month = dec,
|
||||
year = {2012},
|
||||
file = {Full Text PDF:C\:\\Users\\Amaury\\Zotero\\storage\\PYGQL936\\Weiss et al. - 2012 - Logoot-Undo Distributed Collaborative Editing Syst.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{almeida_blocklace_2024,
|
||||
title = {The {Blocklace}: {A} {Universal}, {Byzantine} {Fault}-{Tolerant}, {Conflict}-free {Replicated} {Data} {Type}},
|
||||
shorttitle = {The {Blocklace}},
|
||||
url = {http://arxiv.org/abs/2402.08068},
|
||||
doi = {10.48550/arXiv.2402.08068},
|
||||
abstract = {Conflict-free Replicated Data Types (CRDTs) are designed for replica convergence without global coordination or consensus. Recent work has achieves the same in a Byzantine environment, through DAG-like structures based on cryptographic hashes of content. The blocklace is a partially-ordered generalization of the blockchain in which each block has any finite number of signed hash pointers to preceding blocks. We show that the blocklace datatype, with the sole operation of adding a single block, is a CRDT: it is both a pure operation-based CRDT, with self-tagging; and a delta-state CRDT, under a slight generalization of the delta framework. Allowing arbitrary values as payload, the blocklace can also be seen as a universal Byzantine fault-tolerant implementation for arbitrary CRDTs, under the operation-based approach. Current approaches only care about CRDT convergence, being equivocation-tolerant (they do not detect or prevent equivocations), allowing a Byzantine node to cause an arbitrary amount of harm by polluting the CRDT state with an infinite number of equivocations. We show that a blocklace can be used not only in an equivocation-tolerant way, but also so as to detect and eventually exclude Byzantine behavior, namely equivocations, even under the presence of collusion. The blocklace CRDT protocol ensures that the Byzantine nodes may harm only a finite prefix of the computation.},
|
||||
urldate = {2024-04-12},
|
||||
publisher = {arXiv},
|
||||
author = {Almeida, Paulo Sérgio and Shapiro, Ehud},
|
||||
month = feb,
|
||||
year = {2024},
|
||||
note = {arXiv:2402.08068 [cs]},
|
||||
keywords = {Computer Science - Data Structures and Algorithms, Computer Science - Distributed, Parallel, and Cluster Computing},
|
||||
file = {arXiv Fulltext PDF:C\:\\Users\\Amaury\\Zotero\\storage\\S73ZWXGL\\Almeida et Shapiro - 2024 - The Blocklace A Universal, Byzantine Fault-Tolera.pdf:application/pdf;arXiv.org Snapshot:C\:\\Users\\Amaury\\Zotero\\storage\\J8X5IYE4\\2402.html:text/html},
|
||||
}
|
||||
|
||||
|
||||
@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.},
|
||||
language = {en},
|
||||
number = {1},
|
||||
urldate = {2023-06-06},
|
||||
journal = {ACM SIGOPS Operating Systems Review},
|
||||
author = {Mosberger, David},
|
||||
month = jan,
|
||||
year = {1993},
|
||||
pages = {18--26},
|
||||
file = {Mosberger - 1993 - Memory consistency models.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\VF2ZNK6A\\Mosberger - 1993 - Memory consistency models.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@incollection{goos_causal_1995,
|
||||
address = {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},
|
||||
language = {en},
|
||||
urldate = {2023-06-06},
|
||||
booktitle = {Foundations of {Software} {Technology} and {Theoretical} {Computer} {Science}},
|
||||
publisher = {Springer Berlin Heidelberg},
|
||||
author = {Raynal, Michel and Schiper, André},
|
||||
editor = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan and Thiagarajan, P. S.},
|
||||
year = {1995},
|
||||
doi = {10.1007/3-540-60692-0_48},
|
||||
note = {Series Title: Lecture Notes in Computer Science},
|
||||
pages = {180--194},
|
||||
file = {Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:C\:\\Users\\Amaury\\Zotero\\storage\\B8UNWUSA\\Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf:application/pdf},
|
||||
}
|
||||
|
||||
@phdthesis{kumar_fault-tolerant_2019,
|
||||
type = {{PhD} {Thesis}},
|
||||
title = {Fault-{Tolerant} {Distributed} {Services} in {Message}-{Passing} {Systems}},
|
||||
school = {Texas A\&M University},
|
||||
author = {Kumar, Saptaparni},
|
||||
year = {2019},
|
||||
file = {Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\Q9XK77W9\\Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf:application/pdf;Snapshot:C\:\\Users\\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},
|
||||
shorttitle = {High-{Availability} {Clusters}},
|
||||
url = {http://arxiv.org/abs/2109.15139},
|
||||
doi = {10.1016/j.jss.2021.111208},
|
||||
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.},
|
||||
urldate = {2023-06-06},
|
||||
journal = {Journal of Systems and Software},
|
||||
author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
|
||||
month = may,
|
||||
year = {2022},
|
||||
note = {arXiv: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},
|
||||
pages = {111208},
|
||||
file = {arXiv.org Snapshot:C\:\\Users\\Amaury\\Zotero\\storage\\B4KCP9BG\\2109.html:text/html;Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\K3LQZLC8\\Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@book{MPBook,
|
||||
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.},
|
||||
language = {fr},
|
||||
publisher = {ISTE Group},
|
||||
author = {Perrin, Matthieu},
|
||||
month = sep,
|
||||
year = {2017},
|
||||
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},
|
||||
shorttitle = {Practical client-side replication},
|
||||
url = {https://dl.acm.org/doi/10.14778/3407790.3407847},
|
||||
doi = {10.14778/3407790.3407847},
|
||||
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.},
|
||||
language = {en},
|
||||
number = {12},
|
||||
urldate = {2023-06-06},
|
||||
journal = {Proceedings of the VLDB Endowment},
|
||||
author = {Van Der Linde, Albert and Leitão, João and Preguiça, Nuno},
|
||||
month = aug,
|
||||
year = {2020},
|
||||
pages = {2590--2605},
|
||||
file = {Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\5TJ3SA56\\Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@book{lipton_pram_1988,
|
||||
title = {{PRAM}: {A} {Scalable} {Shared} {Memory}},
|
||||
shorttitle = {{PRAM}},
|
||||
language = {en},
|
||||
publisher = {Princeton University, Department of Computer Science},
|
||||
author = {Lipton, Richard J. and Sandberg, Jonathan S.},
|
||||
year = {1988},
|
||||
note = {Google-Books-ID: 962epwAACAAJ},
|
||||
file = {Lipton et Sandberg - 1988 - PRAM A Scalable Shared Memory.pdf:C\:\\Users\\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},
|
||||
shorttitle = {Slow memory},
|
||||
url = {https://www.computer.org/csdl/proceedings-article/icdcs/1990/00089297/12OmNvSKNPr},
|
||||
doi = {10.1109/ICDCS.1990.89297},
|
||||
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.},
|
||||
language = {English},
|
||||
urldate = {2023-06-06},
|
||||
publisher = {IEEE Computer Society},
|
||||
author = {Hutto, P. W. and Ahamad, M.},
|
||||
month = jan,
|
||||
year = {1990},
|
||||
pages = {302,303,304,305,306,307,308,309--302,303,304,305,306,307,308,309},
|
||||
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.},
|
||||
number = {9},
|
||||
journal = {IEEE Transactions on Computers},
|
||||
author = {{Lamport}},
|
||||
month = sep,
|
||||
year = {1979},
|
||||
note = {Conference Name: IEEE Transactions on Computers},
|
||||
keywords = {Computer design, concurrent computing, hardware correctness, multiprocessing, parallel processing},
|
||||
pages = {690--691},
|
||||
file = {IEEE Xplore Abstract Record:C\:\\Users\\Amaury\\Zotero\\storage\\IVGSSPNE\\1675439.html:text/html;Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\GY8CWGUV\\Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.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.},
|
||||
language = {en},
|
||||
number = {2},
|
||||
urldate = {2023-06-08},
|
||||
journal = {Distributed Computing},
|
||||
author = {Lamport, Leslie},
|
||||
month = jun,
|
||||
year = {1986},
|
||||
keywords = {Communication Network, Computer Hardware, Computer System, Operating System, System Organization},
|
||||
pages = {86--101},
|
||||
file = {Lamport - 1986 - On interprocess communication.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\XV7AEARN\\Lamport - 1986 - On interprocess communication.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.},
|
||||
language = {en},
|
||||
number = {1},
|
||||
urldate = {2023-06-08},
|
||||
journal = {ACM Transactions on Programming Languages and Systems},
|
||||
author = {Misra, J.},
|
||||
month = jan,
|
||||
year = {1986},
|
||||
pages = {142--153},
|
||||
file = {Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:C\:\\Users\\Amaury\\Zotero\\storage\\KZP2774N\\Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf:application/pdf},
|
||||
}
|
||||
|
||||
@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.},
|
||||
language = {en},
|
||||
number = {1},
|
||||
urldate = {2023-06-09},
|
||||
journal = {ACM Computing Surveys},
|
||||
author = {Saito, Yasushi and Shapiro, Marc},
|
||||
year = {2005},
|
||||
pages = {42},
|
||||
file = {Saito et Shapiro - 2005 - Optimistic Replication.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\4WJX5IAN\\Saito et Shapiro - 2005 - Optimistic Replication.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{singh_zeno_2009,
|
||||
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).},
|
||||
language = {en},
|
||||
author = {Singh, Atul and Fonseca, Pedro and Kuznetsov, Petr and Rodrigues, Rodrigo and Maniatis, Petros},
|
||||
year = {2009},
|
||||
file = {Singh et al. - Zeno Eventually Consistent Byzantine-Fault Tolera.pdf:C\:\\Users\\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},
|
||||
shorttitle = {Refresh {Instead} of {Revoke} {Enhances} {Safety} and {Availability}},
|
||||
url = {https://inria.hal.science/hal-02384596},
|
||||
doi = {10.1007/978-3-030-22479-0_16},
|
||||
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.},
|
||||
language = {en},
|
||||
urldate = {2023-06-09},
|
||||
publisher = {Springer International Publishing},
|
||||
author = {Shakarami, Mehrnoosh and Sandhu, Ravi},
|
||||
month = jul,
|
||||
year = {2019},
|
||||
pages = {301},
|
||||
file = {Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\XQNWKF7H\\Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{decandia_dynamo_2007,
|
||||
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.},
|
||||
language = {en},
|
||||
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},
|
||||
year = {2007},
|
||||
file = {DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\KDHRPBGR\\DeCandia et al. - Dynamo Amazon’s Highly Available Key-value Store.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@inproceedings{burckhardt_replicated_2014,
|
||||
address = {San Diego California USA},
|
||||
title = {Replicated data types: specification, verification, optimality},
|
||||
isbn = {978-1-4503-2544-8},
|
||||
shorttitle = {Replicated data types},
|
||||
url = {https://dl.acm.org/doi/10.1145/2535838.2535848},
|
||||
doi = {10.1145/2535838.2535848},
|
||||
abstract = {Geographically distributed systems often rely on replicated eventually consistent data stores to achieve availability and performance. To resolve conflicting updates at different replicas, researchers and practitioners have proposed specialized consistency protocols, called replicated data types, that implement objects such as registers, counters, sets or lists. Reasoning about replicated data types has however not been on par with comparable work on abstract data types and concurrent data types, lacking specifications, correctness proofs, and optimality results.},
|
||||
language = {en},
|
||||
urldate = {2023-11-17},
|
||||
booktitle = {Proceedings of the 41st {ACM} {SIGPLAN}-{SIGACT} {Symposium} on {Principles} of {Programming} {Languages}},
|
||||
publisher = {ACM},
|
||||
author = {Burckhardt, Sebastian and Gotsman, Alexey and Yang, Hongseok and Zawirski, Marek},
|
||||
month = jan,
|
||||
year = {2014},
|
||||
pages = {271--284},
|
||||
file = {Burckhardt et al. - 2014 - Replicated data types specification, verification.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\KQNF7XLE\\Burckhardt et al. - 2014 - Replicated data types specification, verification.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.},
|
||||
booktitle = {2019 {IEEE} 18th {International} {Symposium} on {Network} {Computing} and {Applications} ({NCA})},
|
||||
author = {Tseng, Lewis and Wang, Zezhi and Zhao, Yajie and Pan, Haochen},
|
||||
month = sep,
|
||||
year = {2019},
|
||||
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},
|
||||
pages = {1--8},
|
||||
file = {IEEE Xplore Abstract Record:C\:\\Users\\Amaury\\Zotero\\storage\\DDV34ULW\\8935059.html:text/html},
|
||||
}
|
||||
|
||||
@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.},
|
||||
language = {en},
|
||||
urldate = {2023-07-12},
|
||||
publisher = {arXiv},
|
||||
author = {Misra, Anshuman and Kshemkalyani, Ajay},
|
||||
month = dec,
|
||||
year = {2021},
|
||||
note = {arXiv:2112.11337 [cs]},
|
||||
keywords = {Computer Science - Distributed, Parallel, and Cluster Computing},
|
||||
file = {Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\P2R366US\\Misra and Kshemkalyani - 2021 - Byzantine Fault Tolerant Causal Ordering.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{jacob_analysis_2021,
|
||||
title = {Analysis of the {Matrix} {Event} {Graph} {Replicated} {Data} {Type}},
|
||||
volume = {9},
|
||||
issn = {2169-3536},
|
||||
url = {https://ieeexplore.ieee.org/document/9351908/},
|
||||
doi = {10.1109/ACCESS.2021.3058576},
|
||||
abstract = {Matrix is a new kind of decentralized, topic-based publish-subscribe middleware for communication and data storage that is getting particularly popular as a basis for secure instant messaging. By comparison with traditional decentralized communication systems, Matrix replaces pure message passing with a replicated data structure. This data structure, which we extract and call the Matrix Event Graph (MEG), depicts the causal history of messages. We show that this MEG represents an interesting and important replicated data type for decentralized applications that are based on causal histories of publish-subscribe events: First, we prove that the MEG is a Conflict-Free Replicated Data Type for causal histories and, thus, provides Strong Eventual Consistency (SEC). With SEC being among the best known achievable trade-offs in the scope of the well-known CAP theorem, the MEG provides a powerful consistency guarantee while being available during network partition. Second, we discuss the implications of byzantine attackers on the data type’s properties. We note that the MEG, as it does not strive for consensus or strong consistency, can cope with n {\textgreater} f environments with n participants, of which f are byzantine. Furthermore, we analyze scalability: Using Markov chains, we study the number of forward extremities of the MEG over time and observe an almost optimal evolution. We conjecture that this property is inherent to the underlying spatially inhomogeneous random walk. With the properties shown, a MEG represents a promising element in the set of data structures for decentralized applications, but with distinct trade-offs compared to traditional blockchains and distributed ledger technologies.},
|
||||
language = {en},
|
||||
urldate = {2024-01-12},
|
||||
journal = {IEEE Access},
|
||||
author = {Jacob, Florian and Beer, Carolin and Henze, Norbert and Hartenstein, Hannes},
|
||||
year = {2021},
|
||||
pages = {28317--28333},
|
||||
file = {Jacob et al. - 2021 - Analysis of the Matrix Event Graph Replicated Data.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\TRSMADSW\\Jacob et al. - 2021 - Analysis of the Matrix Event Graph Replicated Data.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@inproceedings{kleppmann_making_2022,
|
||||
address = {Rennes France},
|
||||
title = {Making {CRDTs} {Byzantine} fault tolerant},
|
||||
isbn = {978-1-4503-9256-3},
|
||||
url = {https://dl.acm.org/doi/10.1145/3517209.3524042},
|
||||
doi = {10.1145/3517209.3524042},
|
||||
abstract = {It is often claimed that Conflict-free Replicated Data Types (CRDTs) ensure consistency of replicated data in peer-topeer systems. However, peer-to-peer systems usually consist of untrusted nodes that may deviate from the specified protocol (i.e. exhibit Byzantine faults), and most existing CRDT algorithms cannot guarantee consistency in the presence of such faults. This paper shows how to adapt existing non-Byzantine CRDT algorithms and make them Byzantine fault-tolerant. The proposed scheme can tolerate any number of Byzantine nodes (making it immune to Sybil attacks), guarantees Strong Eventual Consistency, and requires only modest changes to existing CRDT algorithms.},
|
||||
language = {en},
|
||||
urldate = {2024-01-12},
|
||||
booktitle = {Proceedings of the 9th {Workshop} on {Principles} and {Practice} of {Consistency} for {Distributed} {Data}},
|
||||
publisher = {ACM},
|
||||
author = {Kleppmann, Martin},
|
||||
month = apr,
|
||||
year = {2022},
|
||||
pages = {8--15},
|
||||
file = {Kleppmann - 2022 - Making CRDTs Byzantine fault tolerant.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\8K37LERF\\Kleppmann - 2022 - Making CRDTs Byzantine fault tolerant.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{noauthor_yjsyjs_2023,
|
||||
title = {yjs/yjs},
|
||||
url = {https://github.com/yjs/yjs},
|
||||
abstract = {Shared data types for building collaborative software},
|
||||
urldate = {2023-12-10},
|
||||
publisher = {Yjs},
|
||||
month = dec,
|
||||
year = {2023},
|
||||
note = {original-date: 2014-07-29T19:29:45Z},
|
||||
keywords = {collaboration, collaborative-editing, crdt, decentralized, offline-first, p2p, peer-to-peer, realtime, shared-editing, yjs},
|
||||
}
|
||||
|
||||
@misc{appjet_etherpad_2011,
|
||||
title = {Etherpad and {EasySync} {Technical} {Manua}},
|
||||
url = {https://raw.githubusercontent.com/ether/etherpad-lite/master/doc/easysync/easysync-full-description.pdf},
|
||||
urldate = {2023-12-10},
|
||||
author = {AppJet},
|
||||
year = {2011},
|
||||
file = {easysync-full-description.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\F5SV2JTZ\\easysync-full-description.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{kleppmann_conflict-free_2017,
|
||||
title = {A {Conflict}-{Free} {Replicated} {JSON} {Datatype}},
|
||||
volume = {28},
|
||||
issn = {1045-9219},
|
||||
url = {http://arxiv.org/abs/1608.03960},
|
||||
doi = {10.1109/TPDS.2017.2697382},
|
||||
abstract = {Many applications model their data in a general-purpose storage format such as JSON. This data structure is modified by the application as a result of user input. Such modifications are well understood if performed sequentially on a single copy of the data, but if the data is replicated and modified concurrently on multiple devices, it is unclear what the semantics should be. In this paper we present an algorithm and formal semantics for a JSON data structure that automatically resolves concurrent modifications such that no updates are lost, and such that all replicas converge towards the same state (a conflict-free replicated datatype or CRDT). It supports arbitrarily nested list and map types, which can be modified by insertion, deletion and assignment. The algorithm performs all merging client-side and does not depend on ordering guarantees from the network, making it suitable for deployment on mobile devices with poor network connectivity, in peer-to-peer networks, and in messaging systems with end-to-end encryption.},
|
||||
language = {en},
|
||||
number = {10},
|
||||
urldate = {2023-12-10},
|
||||
journal = {IEEE Transactions on Parallel and Distributed Systems},
|
||||
author = {Kleppmann, Martin and Beresford, Alastair R.},
|
||||
month = oct,
|
||||
year = {2017},
|
||||
note = {arXiv:1608.03960 [cs]},
|
||||
keywords = {Computer Science - Distributed, Parallel, and Cluster Computing, Computer Science - Databases},
|
||||
pages = {2733--2746},
|
||||
file = {Kleppmann et Beresford - 2017 - A Conflict-Free Replicated JSON Datatype.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\BQVG57MU\\Kleppmann et Beresford - 2017 - A Conflict-Free Replicated JSON Datatype.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@book{Raynal18,
|
||||
title = {Fault-{Tolerant} {Message}-{Passing} {Distributed} {Systems}: {An} {Algorithmic} {Approach}},
|
||||
isbn = {978-3-319-94141-7},
|
||||
shorttitle = {Fault-{Tolerant} {Message}-{Passing} {Distributed} {Systems}},
|
||||
abstract = {This book presents the most important fault-tolerant distributed programming abstractions and their associated distributed algorithms, in particular in terms of reliable communication and agreement, which lie at the heart of nearly all distributed applications. These programming abstractions, distributed objects or services, allow software designers and programmers to cope with asynchrony and the most important types of failures such as process crashes, message losses, and malicious behaviors of computing entities, widely known under the term "Byzantine fault-tolerance". The author introduces these notions in an incremental manner, starting from a clear specification, followed by algorithms which are first described intuitively and then proved correct. The book also presents impossibility results in classic distributed computing models, along with strategies, mainly failure detectors and randomization, that allow us to enrich these models. In this sense, the book constitutes an introduction to the science of distributed computing, with applications in all domains of distributed systems, such as cloud computing and blockchains. Each chapter comes with exercises and bibliographic notes to help the reader approach, understand, and master the fascinating field of fault-tolerant distributed computing.},
|
||||
language = {en},
|
||||
publisher = {Springer},
|
||||
author = {Raynal, Michel},
|
||||
month = sep,
|
||||
year = {2018},
|
||||
note = {Google-Books-ID: J6BtDwAAQBAJ},
|
||||
keywords = {Computers / Computer Science, Computers / Information Technology, Computers / Networking / General, Technology \& Engineering / Telecommunications},
|
||||
}
|
||||
|
||||
@article{bayuk_data-centric_2009,
|
||||
title = {Data-centric security},
|
||||
volume = {2009},
|
||||
issn = {1361-3723},
|
||||
url = {https://www.sciencedirect.com/science/article/pii/S1361372309700326},
|
||||
doi = {10.1016/S1361-3723(09)70032-6},
|
||||
abstract = {The authoritative control objectives for access to data have always been something along the lines of: “Confirm that user access rights to systems and data are in line with defined and documented business needs, and that job requirements are attached to user identities…. Ensure that critical and confidential information is withheld from those who should not have access to it.”1},
|
||||
number = {3},
|
||||
urldate = {2023-12-08},
|
||||
journal = {Computer Fraud \& Security},
|
||||
author = {Bayuk, Jennifer},
|
||||
month = mar,
|
||||
year = {2009},
|
||||
pages = {7--11},
|
||||
file = {Bayuk - 2009 - Data-centric security.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\2YRZBICQ\\Bayuk - 2009 - Data-centric security.pdf:application/pdf;ScienceDirect Snapshot:C\:\\Users\\Amaury\\Zotero\\storage\\KC3F5F86\\S1361372309700326.html:text/html},
|
||||
}
|
||||
|
||||
@inproceedings{goyal_attribute-based_2006,
|
||||
address = {Alexandria Virginia USA},
|
||||
title = {Attribute-based encryption for fine-grained access control of encrypted data},
|
||||
isbn = {978-1-59593-518-2},
|
||||
url = {https://dl.acm.org/doi/10.1145/1180405.1180418},
|
||||
doi = {10.1145/1180405.1180418},
|
||||
abstract = {As more sensitive data is shared and stored by third-party sites on the Internet, there will be a need to encrypt data stored at these sites. One drawback of encrypting data, is that it can be selectively shared only at a coarse-grained level (i.e., giving another party your private key). We develop a new cryptosystem for fine-grained sharing of encrypted data that we call Key-Policy Attribute-Based Encryption (KP-ABE). In our cryptosystem, ciphertexts are labeled with sets of attributes and private keys are associated with access structures that control which ciphertexts a user is able to decrypt. We demonstrate the applicability of our construction to sharing of audit-log information and broadcast encryption. Our construction supports delegation of private keys which subsumes Hierarchical Identity-Based Encryption (HIBE).},
|
||||
language = {en},
|
||||
urldate = {2023-12-08},
|
||||
booktitle = {Proceedings of the 13th {ACM} conference on {Computer} and communications security},
|
||||
publisher = {ACM},
|
||||
author = {Goyal, Vipul and Pandey, Omkant and Sahai, Amit and Waters, Brent},
|
||||
month = oct,
|
||||
year = {2006},
|
||||
pages = {89--98},
|
||||
file = {Goyal et al. - 2006 - Attribute-based encryption for fine-grained access.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\Z9NEMU4F\\Goyal et al. - 2006 - Attribute-based encryption for fine-grained access.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@incollection{lee_distributed_2009,
|
||||
address = {Berlin, Heidelberg},
|
||||
title = {Distributed {Attribute}-{Based} {Encryption}},
|
||||
volume = {5461},
|
||||
isbn = {978-3-642-00729-3 978-3-642-00730-9},
|
||||
url = {http://link.springer.com/10.1007/978-3-642-00730-9_2},
|
||||
abstract = {Ciphertext-Policy Attribute-Based Encryption (CP-ABE) allows to encrypt data under an access policy, specified as a logical combination of attributes. Such ciphertexts can be decrypted by anyone with a set of attributes that fits the policy. In this paper, we introduce the concept of Distributed Attribute-Based Encryption (DABE), where an arbitrary number of parties can be present to maintain attributes and their corresponding secret keys. This is in stark contrast to the classic CP-ABE schemes, where all secret keys are distributed by one central trusted party. We provide the first construction of a DABE scheme; the construction is very efficient, as it requires only a constant number of pairing operations during encryption and decryption.},
|
||||
language = {en},
|
||||
urldate = {2023-12-08},
|
||||
booktitle = {Information {Security} and {Cryptology} – {ICISC} 2008},
|
||||
publisher = {Springer Berlin Heidelberg},
|
||||
author = {Müller, Sascha and Katzenbeisser, Stefan and Eckert, Claudia},
|
||||
editor = {Lee, Pil Joong and Cheon, Jung Hee},
|
||||
year = {2009},
|
||||
doi = {10.1007/978-3-642-00730-9_2},
|
||||
note = {Series Title: Lecture Notes in Computer Science},
|
||||
pages = {20--36},
|
||||
file = {Müller et al. - 2009 - Distributed Attribute-Based Encryption.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\CWKWPE9S\\Müller et al. - 2009 - Distributed Attribute-Based Encryption.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@techreport{rose_zero_2020,
|
||||
title = {Zero {Trust} {Architecture}},
|
||||
url = {https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf},
|
||||
abstract = {Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterpriseowned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource. This document contains an abstract definition of zero trust architecture (ZTA) and gives general deployment models and use cases where zero trust could improve an enterprise’s overall information technology security posture.},
|
||||
language = {en},
|
||||
urldate = {2023-12-08},
|
||||
institution = {National Institute of Standards and Technology},
|
||||
author = {Rose, Scott and Borchert, Oliver and Mitchell, Stu and Connelly, Sean},
|
||||
month = aug,
|
||||
year = {2020},
|
||||
doi = {10.6028/NIST.SP.800-207},
|
||||
file = {Rose et al. - 2020 - Zero Trust Architecture.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\6PRUAJZ3\\Rose et al. - 2020 - Zero Trust Architecture.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@article{yan_flexible_2017,
|
||||
title = {Flexible {Data} {Access} {Control} {Based} on {Trust} and {Reputation} in {Cloud} {Computing}},
|
||||
volume = {5},
|
||||
issn = {2168-7161},
|
||||
url = {http://ieeexplore.ieee.org/document/7208817/},
|
||||
doi = {10.1109/TCC.2015.2469662},
|
||||
abstract = {Cloud computing offers a new way of services and has become a popular service platform. Storing user data at a cloud data center greatly releases storage burden of user devices and brings access convenience. Due to distrust in cloud service providers, users generally store their crucial data in an encrypted form. But in many cases, the data need to be accessed by other entities for fulfilling an expected service, e.g., an eHealth service. How to control personal data access at cloud is a critical issue. Various application scenarios request flexible control on cloud data access based on data owner policies and application demands. Either data owners or some trusted third parties or both should flexibly participate in this control. However, existing work hasn’t yet investigated an effective and flexible solution to satisfy this demand. On the other hand, trust plays an important role in data sharing. It helps overcoming uncertainty and avoiding potential risks. But literature still lacks a practical solution to control cloud data access based on trust and reputation. In this paper, we propose a scheme to control data access in cloud computing based on trust evaluated by the data owner and/or reputations generated by a number of reputation centers in a flexible manner by applying Attribue-Based Encryption and Proxy Re-Encryption. We integrate the concept of context-aware trust and reputation evaluation into a cryptographic system in order to support various control scenarios and strategies. The security and performance of our scheme are evaluated and justified through extensive analysis, security proof, comparison and implementation. The results show the efficiency, flexibility and effectiveness of our scheme for data access control in cloud computing.},
|
||||
language = {en},
|
||||
number = {3},
|
||||
urldate = {2023-12-08},
|
||||
journal = {IEEE Transactions on Cloud Computing},
|
||||
author = {Yan, Zheng and Li, Xueyun and Wang, Mingjun and Vasilakos, Athanasios V.},
|
||||
month = jul,
|
||||
year = {2017},
|
||||
pages = {485--498},
|
||||
file = {Yan et al. - 2017 - Flexible Data Access Control Based on Trust and Re.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\EGDZNP8U\\Yan et al. - 2017 - Flexible Data Access Control Based on Trust and Re.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@inproceedings{preguica_commutative_2009,
|
||||
address = {Montreal, Quebec, Canada},
|
||||
title = {A {Commutative} {Replicated} {Data} {Type} for {Cooperative} {Editing}},
|
||||
url = {http://ieeexplore.ieee.org/document/5158449/},
|
||||
doi = {10.1109/ICDCS.2009.20},
|
||||
abstract = {A Commutative Replicated Data Type (CRDT) is one where all concurrent operations commute. The replicas of a CRDT converge automatically, without complex concurrency control. This paper describes Treedoc, a novel CRDT design for cooperative text editing. An essential property is that the identifiers of Treedoc atoms are selected from a dense space. We discuss practical alternatives for implementing the identifier space based on an extended binary tree. We also discuss storage alternatives for data and meta-data, and mechanisms for compacting the tree. In the best case, Treedoc incurs no overhead with respect to a linear text buffer. We validate the results with traces from existing edit histories.},
|
||||
language = {en},
|
||||
urldate = {2024-02-16},
|
||||
booktitle = {2009 29th {IEEE} {International} {Conference} on {Distributed} {Computing} {Systems}},
|
||||
publisher = {IEEE},
|
||||
author = {Preguica, Nuno and Marques, Joan Manuel and Shapiro, Marc and Letia, Mihai},
|
||||
month = jun,
|
||||
year = {2009},
|
||||
pages = {395--403},
|
||||
file = {Preguica et al. - 2009 - A Commutative Replicated Data Type for Cooperative.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\LKX6LUIS\\Preguica et al. - 2009 - A Commutative Replicated Data Type for Cooperative.pdf:application/pdf},
|
||||
}
|
||||
|
||||
|
||||
@incollection{defago_conflict-free_2011,
|
||||
address = {Berlin, Heidelberg},
|
||||
title = {Conflict-{Free} {Replicated} {Data} {Types}},
|
||||
volume = {6976},
|
||||
isbn = {978-3-642-24549-7 978-3-642-24550-3},
|
||||
url = {http://link.springer.com/10.1007/978-3-642-24550-3_29},
|
||||
abstract = {Replicating data under Eventual Consistency (EC) allows any replica to accept updates without remote synchronisation. This ensures performance and scalability in large-scale distributed systems (e.g., clouds). However, published EC approaches are ad-hoc and error-prone. Under a formal Strong Eventual Consistency (SEC) model, we study sufficient conditions for convergence. A data type that satisfies these conditions is called a Conflict-free Replicated Data Type (CRDT). Replicas of any CRDT are guaranteed to converge in a self-stabilising manner, despite any number of failures. This paper formalises two popular approaches (state- and operation-based) and their relevant sufficient conditions. We study a number of useful CRDTs, such as sets with clean semantics, supporting both add and remove operations, and consider in depth the more complex Graph data type. CRDT types can be composed to develop large-scale distributed applications, and have interesting theoretical properties.},
|
||||
language = {en},
|
||||
urldate = {2023-12-08},
|
||||
booktitle = {Stabilization, {Safety}, and {Security} of {Distributed} {Systems}},
|
||||
publisher = {Springer Berlin Heidelberg},
|
||||
author = {Shapiro, Marc and Preguiça, Nuno and Baquero, Carlos and Zawirski, Marek},
|
||||
editor = {Défago, Xavier and Petit, Franck and Villain, Vincent},
|
||||
year = {2011},
|
||||
doi = {10.1007/978-3-642-24550-3_29},
|
||||
note = {Series Title: Lecture Notes in Computer Science},
|
||||
pages = {386--400},
|
||||
file = {Shapiro et al. - 2011 - Conflict-Free Replicated Data Types.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\QK99TF5K\\Shapiro et al. - 2011 - Conflict-Free Replicated Data Types.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@inproceedings{nicolaescu_near_2016,
|
||||
address = {Sanibel Island Florida USA},
|
||||
title = {Near {Real}-{Time} {Peer}-to-{Peer} {Shared} {Editing} on {Extensible} {Data} {Types}},
|
||||
isbn = {978-1-4503-4276-6},
|
||||
url = {https://dl.acm.org/doi/10.1145/2957276.2957310},
|
||||
doi = {10.1145/2957276.2957310},
|
||||
language = {en},
|
||||
urldate = {2023-12-01},
|
||||
booktitle = {Proceedings of the 19th {International} {Conference} on {Supporting} {Group} {Work}},
|
||||
publisher = {ACM},
|
||||
author = {Nicolaescu, Petru and Jahns, Kevin and Derntl, Michael and Klamma, Ralf},
|
||||
month = nov,
|
||||
year = {2016},
|
||||
pages = {39--49},
|
||||
file = {Nicolaescu et al. - 2016 - Near Real-Time Peer-to-Peer Shared Editing on Exte.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\SV3MSLKD\\Nicolaescu et al. - 2016 - Near Real-Time Peer-to-Peer Shared Editing on Exte.pdf:application/pdf},
|
||||
}
|
||||
|
||||
@misc{frey_process-commutative_2023,
|
||||
title = {Process-{Commutative} {Distributed} {Objects}: {From} {Cryptocurrencies} to {Byzantine}-{Fault}-{Tolerant} {CRDTs}},
|
||||
shorttitle = {Process-{Commutative} {Distributed} {Objects}},
|
||||
url = {http://arxiv.org/abs/2311.13936},
|
||||
abstract = {This paper explores the territory that lies between best-effort Byzantine-Fault-Tolerant Conflict-free Replicated Data Types (BFT CRDTs) and totally ordered distributed ledgers. It formally characterizes a novel class of distributed objects that only requires a First In First Out (FIFO) order on the object operations from each process (taken individually). The formalization relies on Mazurkiewicz traces to define legal sequences of operations and ensure a combination of Strong Eventual Consistency (SEC) and Pipleline Consistency (PC). The paper presents a generic algorithm that implements this novel class of distributed objects both in a crash- and Byzantine setting. Finally, the proposed approach is illustrated with four instances of this class of objects, namely money transfer, Petri nets, multi-sets, and concurrent work stealing dequeues.},
|
||||
language = {en},
|
||||
urldate = {2024-01-22},
|
||||
publisher = {arXiv},
|
||||
author = {Frey, Davide and Guillou, Lucie and Raynal, Michel and Taïani, François},
|
||||
month = nov,
|
||||
year = {2023},
|
||||
note = {arXiv:2311.13936 [cs]},
|
||||
keywords = {Computer Science - Distributed, Parallel, and Cluster Computing},
|
||||
file = {Frey et al. - 2023 - Process-Commutative Distributed Objects From Cryp.pdf:C\:\\Users\\Amaury\\Zotero\\storage\\FUPJTWVD\\Frey et al. - 2023 - Process-Commutative Distributed Objects From Cryp.pdf:application/pdf},
|
||||
}
|
||||
462
docs/sujetThese/sujet-cifre.bib
Normal file
462
docs/sujetThese/sujet-cifre.bib
Normal file
@ -0,0 +1,462 @@
|
||||
@misc{AppJetEtherpad2011,
|
||||
title = {Etherpad and {{EasySync Technical Manual}}},
|
||||
author = {AppJet},
|
||||
year = {2011},
|
||||
urldate = {2023-12-10},
|
||||
howpublished = {https://raw.githubusercontent.com/ether/etherpad-lite/master/doc/easysync/easysync-full-description.pdf},
|
||||
file = {/home/amaury/Zotero/storage/F5SV2JTZ/easysync-full-description.pdf}
|
||||
}
|
||||
|
||||
@article{BayukDatacentric2009,
|
||||
title = {Data-Centric Security},
|
||||
author = {Bayuk, Jennifer},
|
||||
year = {2009},
|
||||
month = mar,
|
||||
journal = {Computer Fraud \& Security},
|
||||
volume = {2009},
|
||||
number = {3},
|
||||
pages = {7--11},
|
||||
issn = {1361-3723},
|
||||
doi = {10.1016/S1361-3723(09)70032-6},
|
||||
urldate = {2023-12-08},
|
||||
abstract = {The authoritative control objectives for access to data have always been something along the lines of: ``Confirm that user access rights to systems and data are in line with defined and documented business needs, and that job requirements are attached to user identities{\ldots}. Ensure that critical and confidential information is withheld from those who should not have access to it.''1},
|
||||
file = {/home/amaury/Zotero/storage/2YRZBICQ/Bayuk - 2009 - Data-centric security.pdf;/home/amaury/Zotero/storage/KC3F5F86/S1361372309700326.html}
|
||||
}
|
||||
|
||||
@inproceedings{BurckhardtReplicated2014,
|
||||
title = {Replicated Data Types: Specification, Verification, Optimality},
|
||||
shorttitle = {Replicated Data Types},
|
||||
booktitle = {Proceedings of the 41st {{ACM SIGPLAN-SIGACT Symposium}} on {{Principles}} of {{Programming Languages}}},
|
||||
author = {Burckhardt, Sebastian and Gotsman, Alexey and Yang, Hongseok and Zawirski, Marek},
|
||||
year = {2014},
|
||||
month = jan,
|
||||
pages = {271--284},
|
||||
publisher = {{ACM}},
|
||||
address = {{San Diego California USA}},
|
||||
doi = {10.1145/2535838.2535848},
|
||||
urldate = {2023-11-17},
|
||||
abstract = {Geographically distributed systems often rely on replicated eventually consistent data stores to achieve availability and performance. To resolve conflicting updates at different replicas, researchers and practitioners have proposed specialized consistency protocols, called replicated data types, that implement objects such as registers, counters, sets or lists. Reasoning about replicated data types has however not been on par with comparable work on abstract data types and concurrent data types, lacking specifications, correctness proofs, and optimality results.},
|
||||
isbn = {978-1-4503-2544-8},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/KQNF7XLE/Burckhardt et al. - 2014 - Replicated data types specification, verification.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{DeCandiaDynamo2007,
|
||||
author = {Giuseppe DeCandia and
|
||||
Deniz Hastorun and
|
||||
Madan Jampani and
|
||||
Gunavardhan Kakulapati and
|
||||
Avinash Lakshman and
|
||||
Alex Pilchin and
|
||||
Swaminathan Sivasubramanian and
|
||||
Peter Vosshall and
|
||||
Werner Vogels},
|
||||
editor = {Thomas C. Bressoud and
|
||||
M. Frans Kaashoek},
|
||||
title = {Dynamo: amazon's highly available key-value store},
|
||||
booktitle = {Proceedings of the 21st {ACM} Symposium on Operating Systems Principles
|
||||
({SOSP})},
|
||||
pages = {205--220},
|
||||
publisher = {{ACM}},
|
||||
year = {2007},
|
||||
url = {https://doi.org/10.1145/1294261.1294281},
|
||||
doi = {10.1145/1294261.1294281},
|
||||
timestamp = {Wed, 14 Nov 2018 10:55:11 +0100},
|
||||
biburl = {https://dblp.org/rec/conf/sosp/DeCandiaHJKLPSVV07.bib},
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
@inproceedings{GoyalAttributebased2006,
|
||||
title = {Attribute-Based Encryption for Fine-Grained Access Control of Encrypted Data},
|
||||
booktitle = {Proceedings of the 13th {{ACM}} Conference on {{Computer}} and Communications Security},
|
||||
author = {Goyal, Vipul and Pandey, Omkant and Sahai, Amit and Waters, Brent},
|
||||
year = {2006},
|
||||
month = oct,
|
||||
pages = {89--98},
|
||||
publisher = {{ACM}},
|
||||
doi = {10.1145/1180405.1180418},
|
||||
urldate = {2023-12-08},
|
||||
abstract = {As more sensitive data is shared and stored by third-party sites on the Internet, there will be a need to encrypt data stored at these sites. One drawback of encrypting data, is that it can be selectively shared only at a coarse-grained level (i.e., giving another party your private key). We develop a new cryptosystem for fine-grained sharing of encrypted data that we call Key-Policy Attribute-Based Encryption (KP-ABE). In our cryptosystem, ciphertexts are labeled with sets of attributes and private keys are associated with access structures that control which ciphertexts a user is able to decrypt. We demonstrate the applicability of our construction to sharing of audit-log information and broadcast encryption. Our construction supports delegation of private keys which subsumes Hierarchical Identity-Based Encryption (HIBE).},
|
||||
isbn = {978-1-59593-518-2},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/Z9NEMU4F/Goyal et al. - 2006 - Attribute-based encryption for fine-grained access.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{HuttoSlow1990,
|
||||
title = {Slow Memory: Weakening Consistency to Enhance Concurrency in Distributed Shared Memories},
|
||||
shorttitle = {Slow Memory},
|
||||
booktitle = {Proceedings.,10th {{International Conference}} on {{Distributed Computing Systems}}},
|
||||
author = {Hutto, P. W. and Ahamad, M.},
|
||||
year = {1990},
|
||||
month = jan,
|
||||
pages = {302--309},
|
||||
publisher = {{IEEE Computer Society}},
|
||||
doi = {10.1109/ICDCS.1990.89297},
|
||||
urldate = {2023-06-06},
|
||||
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.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Téléchargements/Hutto et Ahamad - 1990 - Slow memory weakening consistency to enhance conc.pdf}
|
||||
}
|
||||
|
||||
@article{KleppmannConflictFree2017,
|
||||
title = {A {{Conflict-Free Replicated JSON Datatype}}},
|
||||
author = {Kleppmann, Martin and Beresford, Alastair R.},
|
||||
year = {2017},
|
||||
month = oct,
|
||||
journal = {IEEE Transactions on Parallel and Distributed Systems},
|
||||
volume = {28},
|
||||
number = {10},
|
||||
eprint = {1608.03960},
|
||||
primaryclass = {cs},
|
||||
pages = {2733--2746},
|
||||
issn = {1045-9219},
|
||||
doi = {10.1109/TPDS.2017.2697382},
|
||||
urldate = {2023-12-10},
|
||||
abstract = {Many applications model their data in a general-purpose storage format such as JSON. This data structure is modified by the application as a result of user input. Such modifications are well understood if performed sequentially on a single copy of the data, but if the data is replicated and modified concurrently on multiple devices, it is unclear what the semantics should be. In this paper we present an algorithm and formal semantics for a JSON data structure that automatically resolves concurrent modifications such that no updates are lost, and such that all replicas converge towards the same state (a conflict-free replicated datatype or CRDT). It supports arbitrarily nested list and map types, which can be modified by insertion, deletion and assignment. The algorithm performs all merging client-side and does not depend on ordering guarantees from the network, making it suitable for deployment on mobile devices with poor network connectivity, in peer-to-peer networks, and in messaging systems with end-to-end encryption.},
|
||||
archiveprefix = {arxiv},
|
||||
langid = {english},
|
||||
keywords = {Computer Science - Databases,{Computer Science - Distributed, Parallel, and Cluster Computing}},
|
||||
file = {/home/amaury/Zotero/storage/BQVG57MU/Kleppmann et Beresford - 2017 - A Conflict-Free Replicated JSON Datatype.pdf}
|
||||
}
|
||||
|
||||
@phdthesis{KumarFaultTolerant2019,
|
||||
title = {Fault-{{Tolerant Distributed Services}} in {{Message-Passing Systems}}},
|
||||
author = {Kumar, Saptaparni},
|
||||
year = {2019},
|
||||
school = {Texas A\&M University},
|
||||
file = {/home/amaury/Zotero/storage/Q9XK77W9/Kumar - 2019 - Fault-Tolerant Distributed Services in Message-Pas.pdf;/home/amaury/Zotero/storage/7JB26RAJ/1.html}
|
||||
}
|
||||
|
||||
@article{LamportHow1979,
|
||||
title = {How to {{Make}} a {{Multiprocessor Computer That Correctly Executes Multiprocess Programs}}},
|
||||
author = {{Lamport}},
|
||||
year = {1979},
|
||||
month = sep,
|
||||
journal = {IEEE Transactions on Computers},
|
||||
volume = {C-28},
|
||||
number = {9},
|
||||
pages = {690--691},
|
||||
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.},
|
||||
keywords = {Computer design,concurrent computing,hardware correctness,multiprocessing,parallel processing},
|
||||
file = {/home/amaury/Zotero/storage/GY8CWGUV/Lamport - 1979 - How to Make a Multiprocessor Computer That Correct.pdf;/home/amaury/Zotero/storage/IVGSSPNE/1675439.html}
|
||||
}
|
||||
|
||||
@article{LamportInterprocess1986,
|
||||
title = {On Interprocess Communication},
|
||||
author = {Lamport, Leslie},
|
||||
year = {1986},
|
||||
month = jun,
|
||||
journal = {Distributed Computing},
|
||||
volume = {1},
|
||||
number = {2},
|
||||
pages = {86--101},
|
||||
issn = {1432-0452},
|
||||
doi = {10.1007/BF01786228},
|
||||
urldate = {2023-06-08},
|
||||
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.},
|
||||
langid = {english},
|
||||
keywords = {Communication Network,Computer Hardware,Computer System,Operating System,System Organization},
|
||||
file = {/home/amaury/Zotero/storage/XV7AEARN/Lamport - 1986 - On interprocess communication.pdf}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@TechReport{LiptonPRAM1988,
|
||||
author = {Lipton, Richard J. and Sandberg, Jonathan S.},
|
||||
title = {{{PRAM}}: {{A Scalable Shared Memory}}},
|
||||
institution = {Princeton University, Department of Computer Science},
|
||||
year = 1988,
|
||||
key = {TR-180-88 }}
|
||||
|
||||
|
||||
@article{MisraAxioms1986,
|
||||
title = {Axioms for Memory Access in Asynchronous Hardware Systems},
|
||||
author = {Misra, J.},
|
||||
year = {1986},
|
||||
month = jan,
|
||||
journal = {ACM Transactions on Programming Languages and Systems},
|
||||
volume = {8},
|
||||
number = {1},
|
||||
pages = {142--153},
|
||||
issn = {0164-0925, 1558-4593},
|
||||
doi = {10.1145/5001.5007},
|
||||
urldate = {2023-06-08},
|
||||
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.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/KZP2774N/Misra - 1986 - Axioms for memory access in asynchronous hardware .pdf}
|
||||
}
|
||||
|
||||
|
||||
@inproceedings{MisraByzantine2021,
|
||||
author = {Anshuman Misra and
|
||||
Ajay D. Kshemkalyani},
|
||||
title = {Byzantine Fault-Tolerant Causal Ordering},
|
||||
booktitle = {24th International Conference on Distributed Computing and Networking,
|
||||
({ICDCN})},
|
||||
pages = {100--109},
|
||||
publisher = {{ACM}},
|
||||
year = {2023},
|
||||
url = {https://doi.org/10.1145/3571306.3571395},
|
||||
doi = {10.1145/3571306.3571395},
|
||||
timestamp = {Sun, 15 Jan 2023 18:32:09 +0100},
|
||||
biburl = {https://dblp.org/rec/conf/icdcn/MisraK23.bib},
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
|
||||
@article{MosbergerMemory1993,
|
||||
title = {Memory Consistency Models},
|
||||
author = {Mosberger, David},
|
||||
year = {1993},
|
||||
month = jan,
|
||||
journal = {ACM SIGOPS Operating Systems Review},
|
||||
volume = {27},
|
||||
number = {1},
|
||||
pages = {18--26},
|
||||
issn = {0163-5980},
|
||||
doi = {10.1145/160551.160553},
|
||||
urldate = {2023-06-06},
|
||||
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.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/VF2ZNK6A/Mosberger - 1993 - Memory consistency models.pdf}
|
||||
}
|
||||
|
||||
@book{MPBook,
|
||||
title = {{Concurrence et coh{\'e}rence dans les syst{\`e}mes r{\'e}partis}},
|
||||
author = {Perrin, Matthieu},
|
||||
year = {2017},
|
||||
month = sep,
|
||||
publisher = {{ISTE Group}},
|
||||
abstract = {La soci{\'e}t{\'e} moderne est de plus en plus domin{\'e}e par la soci{\'e}t{\'e} virtuelle, le nombre d'internautes dans le monde ayant d{\'e}pass{\'e} les trois milliards en 2015. A la diff{\'e}rence de leurs homologues s{\'e}quentiels, les syst{\`e}mes r{\'e}partis sont beaucoup plus difficiles {\`a} concevoir, et sont donc sujets {\`a} de nombreux probl{\`e}mes.La coh{\'e}rence s{\'e}quentielle fournit la m{\^e}me vue globale {\`a} tous les utilisateurs, mais le confort d\&\#39;utilisation qu\&\#39;elle apporte est trop co{\^u}teux, voire impossible, {\`a} mettre en oeuvre {\`a} grande {\'e}chelle.~Concurrence et coh{\'e}rence dans les syst{\`e}mes r{\'e}partis~examine les meilleures fa{\c c}ons de sp{\'e}cifier les objets que l'on peut tout de m{\^e}me impl{\'e}menter dans ces syst{\`e}mes.Cet ouvrage explore la zone grise des syst{\`e}mes r{\'e}partis et dresse une carte des crit{\`e}res de coh{\'e}rence faible, identifiant plusieurs familles et d{\'e}montrant comment elles peuvent s'int{\'e}grer dans un langage de programmation.},
|
||||
googlebooks = {6DRlDwAAQBAJ},
|
||||
isbn = {978-1-78405-295-9},
|
||||
langid = {french},
|
||||
file = {/home/amaury/Téléchargements/Perrin - 2017 - Concurrence et cohérence dans les systèmes réparti.pdf}
|
||||
}
|
||||
|
||||
@incollection{MullerDistributed2009,
|
||||
title = {Distributed {{Attribute-Based Encryption}}},
|
||||
booktitle = {Information {{Security}} and {{Cryptology}} {\textendash} {{ICISC}} 2008},
|
||||
author = {M{\"u}ller, Sascha and Katzenbeisser, Stefan and Eckert, Claudia},
|
||||
editor = {Lee, Pil Joong and Cheon, Jung Hee},
|
||||
year = {2009},
|
||||
volume = {5461},
|
||||
pages = {20--36},
|
||||
publisher = {{Springer Berlin Heidelberg}},
|
||||
address = {{Berlin, Heidelberg}},
|
||||
doi = {10.1007/978-3-642-00730-9_2},
|
||||
urldate = {2023-12-08},
|
||||
abstract = {Ciphertext-Policy Attribute-Based Encryption (CP-ABE) allows to encrypt data under an access policy, specified as a logical combination of attributes. Such ciphertexts can be decrypted by anyone with a set of attributes that fits the policy. In this paper, we introduce the concept of Distributed Attribute-Based Encryption (DABE), where an arbitrary number of parties can be present to maintain attributes and their corresponding secret keys. This is in stark contrast to the classic CP-ABE schemes, where all secret keys are distributed by one central trusted party. We provide the first construction of a DABE scheme; the construction is very efficient, as it requires only a constant number of pairing operations during encryption and decryption.},
|
||||
isbn = {978-3-642-00729-3 978-3-642-00730-9},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/CWKWPE9S/Müller et al. - 2009 - Distributed Attribute-Based Encryption.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{NicolaescuRealTime2016,
|
||||
title = {Near {{Real-Time Peer-to-Peer Shared Editing}} on {{Extensible Data Types}}},
|
||||
booktitle = {Proceedings of the 19th {{International Conference}} on {{Supporting Group Work}}},
|
||||
author = {Nicolaescu, Petru and Jahns, Kevin and Derntl, Michael and Klamma, Ralf},
|
||||
year = {2016},
|
||||
month = nov,
|
||||
pages = {39--49},
|
||||
publisher = {{ACM}},
|
||||
doi = {10.1145/2957276.2957310},
|
||||
urldate = {2023-12-01},
|
||||
isbn = {978-1-4503-4276-6},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/SV3MSLKD/Nicolaescu et al. - 2016 - Near Real-Time Peer-to-Peer Shared Editing on Exte.pdf}
|
||||
}
|
||||
|
||||
@book{Raynal18,
|
||||
title = {Fault-{{Tolerant Message-Passing Distributed Systems}}: {{An Algorithmic Approach}}},
|
||||
shorttitle = {Fault-{{Tolerant Message-Passing Distributed Systems}}},
|
||||
author = {Raynal, Michel},
|
||||
year = {2018},
|
||||
month = sep,
|
||||
publisher = {{Springer}},
|
||||
abstract = {This book presents the most important fault-tolerant distributed programming abstractions and their associated distributed algorithms, in particular in terms of reliable communication and agreement, which lie at the heart of nearly all distributed applications. These programming abstractions, distributed objects or services, allow software designers and programmers to cope with asynchrony and the most important types of failures such as process crashes, message losses, and malicious behaviors of computing entities, widely known under the term "Byzantine fault-tolerance". The author introduces these notions in an incremental manner, starting from a clear specification, followed by algorithms which are first described intuitively and then proved correct. The book also presents impossibility results in classic distributed computing models, along with strategies, mainly failure detectors and randomization, that allow us to enrich these models. In this sense, the book constitutes an introduction to the science of distributed computing, with applications in all domains of distributed systems, such as cloud computing and blockchains. Each chapter comes with exercises and bibliographic notes to help the reader approach, understand, and master the fascinating field of fault-tolerant distributed computing.},
|
||||
googlebooks = {J6BtDwAAQBAJ},
|
||||
isbn = {978-3-319-94141-7},
|
||||
langid = {english},
|
||||
keywords = {Computers / Computer Science,Computers / Information Technology,Computers / Networking / General,Technology \& Engineering / Telecommunications}
|
||||
}
|
||||
|
||||
@incollection{RaynalCausal1995,
|
||||
title = {From Causal Consistency to Sequential Consistency in Shared Memory Systems},
|
||||
booktitle = {Foundations of {{Software Technology}} and {{Theoretical Computer Science}}},
|
||||
author = {Raynal, Michel and Schiper, Andr{\'e}},
|
||||
editor = {Goos, Gerhard and Hartmanis, Juris and Leeuwen, Jan and Thiagarajan, P. S.},
|
||||
year = {1995},
|
||||
volume = {1026},
|
||||
pages = {180--194},
|
||||
publisher = {{Springer Berlin Heidelberg}},
|
||||
address = {{Berlin, Heidelberg}},
|
||||
doi = {10.1007/3-540-60692-0_48},
|
||||
urldate = {2023-06-06},
|
||||
isbn = {978-3-540-60692-5 978-3-540-49263-4},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/B8UNWUSA/Raynal et Schiper - 1995 - From causal consistency to sequential consistency .pdf}
|
||||
}
|
||||
|
||||
@techreport{RoseZero2020,
|
||||
title = {Zero {{Trust Architecture}}},
|
||||
author = {Rose, Scott and Borchert, Oliver and Mitchell, Stu and Connelly, Sean},
|
||||
year = {2020},
|
||||
month = aug,
|
||||
institution = {{National Institute of Standards and Technology}},
|
||||
doi = {10.6028/NIST.SP.800-207},
|
||||
urldate = {2023-12-08},
|
||||
abstract = {Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. A zero trust architecture (ZTA) uses zero trust principles to plan industrial and enterprise infrastructure and workflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned). Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established. Zero trust is a response to enterprise network trends that include remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterpriseowned network boundary. Zero trust focuses on protecting resources (assets, services, workflows, network accounts, etc.), not network segments, as the network location is no longer seen as the prime component to the security posture of the resource. This document contains an abstract definition of zero trust architecture (ZTA) and gives general deployment models and use cases where zero trust could improve an enterprise's overall information technology security posture.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/6PRUAJZ3/Rose et al. - 2020 - Zero Trust Architecture.pdf}
|
||||
}
|
||||
|
||||
@article{SaitoOptimistic2005,
|
||||
title = {Optimistic {{Replication}}},
|
||||
author = {Saito, Yasushi and Shapiro, Marc},
|
||||
year = {2005},
|
||||
journal = {ACM Computing Surveys},
|
||||
volume = {37},
|
||||
number = {1},
|
||||
pages = {42},
|
||||
doi = {10.1145/1057977.1057980},
|
||||
urldate = {2023-06-09},
|
||||
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.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/4WJX5IAN/Saito et Shapiro - 2005 - Optimistic Replication.pdf}
|
||||
}
|
||||
|
||||
@inproceedings{ShakaramiRefresh2019,
|
||||
title = {Refresh {{Instead}} of {{Revoke Enhances Safety}} and {{Availability}}: {{A Formal Analysis}}},
|
||||
shorttitle = {Refresh {{Instead}} of {{Revoke Enhances Safety}} and {{Availability}}},
|
||||
booktitle = {33th {{IFIP Annual Conference}} on {{Data}} and {{Applications Security}} and {{Privacy}} ({{DBSec}})},
|
||||
author = {Shakarami, Mehrnoosh and Sandhu, Ravi},
|
||||
year = {2019},
|
||||
month = jul,
|
||||
volume = {LNCS-11559},
|
||||
pages = {301},
|
||||
publisher = {{Springer International Publishing}},
|
||||
doi = {10.1007/978-3-030-22479-0_16},
|
||||
urldate = {2023-06-09},
|
||||
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.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/XQNWKF7H/Shakarami et Sandhu - 2019 - Refresh Instead of Revoke Enhances Safety and Avai.pdf}
|
||||
}
|
||||
|
||||
@incollection{ShapiroConflictFree2011,
|
||||
title = {Conflict-{{Free Replicated Data Types}}},
|
||||
booktitle = {Stabilization, {{Safety}}, and {{Security}} of {{Distributed Systems}}},
|
||||
author = {Shapiro, Marc and Pregui{\c c}a, Nuno and Baquero, Carlos and Zawirski, Marek},
|
||||
year = {2011},
|
||||
volume = {6976},
|
||||
pages = {386--400},
|
||||
publisher = {{Springer Berlin Heidelberg}},
|
||||
address = {{Berlin, Heidelberg}},
|
||||
doi = {10.1007/978-3-642-24550-3_29},
|
||||
urldate = {2023-12-08},
|
||||
abstract = {Replicating data under Eventual Consistency (EC) allows any replica to accept updates without remote synchronisation. This ensures performance and scalability in large-scale distributed systems (e.g., clouds). However, published EC approaches are ad-hoc and error-prone. Under a formal Strong Eventual Consistency (SEC) model, we study sufficient conditions for convergence. A data type that satisfies these conditions is called a Conflict-free Replicated Data Type (CRDT). Replicas of any CRDT are guaranteed to converge in a self-stabilising manner, despite any number of failures. This paper formalises two popular approaches (state- and operation-based) and their relevant sufficient conditions. We study a number of useful CRDTs, such as sets with clean semantics, supporting both add and remove operations, and consider in depth the more complex Graph data type. CRDT types can be composed to develop large-scale distributed applications, and have interesting theoretical properties.},
|
||||
isbn = {978-3-642-24549-7 978-3-642-24550-3},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/QK99TF5K/Shapiro et al. - 2011 - Conflict-Free Replicated Data Types.pdf}
|
||||
}
|
||||
|
||||
|
||||
@inproceedings{SinghZeno2009,
|
||||
author = {Atul Singh and
|
||||
Pedro Fonseca and
|
||||
Petr Kuznetsov and
|
||||
Rodrigo Rodrigues and
|
||||
Petros Maniatis},
|
||||
editor = {Jennifer Rexford and
|
||||
Emin G{\"{u}}n Sirer},
|
||||
title = {Zeno: Eventually Consistent Byzantine-Fault Tolerance},
|
||||
booktitle = {Proceedings of the 6th {USENIX} Symposium on Networked Systems Design
|
||||
and Implementation ({NSDI})},
|
||||
pages = {169--184},
|
||||
publisher = {{USENIX} Association},
|
||||
year = {2009},
|
||||
url = {http://www.usenix.org/events/nsdi09/tech/full\_papers/singh/singh.pdf},
|
||||
timestamp = {Thu, 12 Nov 2020 16:34:18 +0100},
|
||||
biburl = {https://dblp.org/rec/conf/nsdi/SinghFKRM09.bib},
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
|
||||
@article{SomasekaramHighAvailability2022,
|
||||
title = {High-{{Availability Clusters}}: {{A Taxonomy}}, {{Survey}}, and {{Future Directions}}},
|
||||
shorttitle = {High-{{Availability Clusters}}},
|
||||
author = {Somasekaram, Premathas and Calinescu, Radu and Buyya, Rajkumar},
|
||||
year = {2022},
|
||||
month = may,
|
||||
journal = {Journal of Systems and Software},
|
||||
volume = {187},
|
||||
eprint = {2109.15139},
|
||||
primaryclass = {cs, eess},
|
||||
pages = {111208},
|
||||
issn = {01641212},
|
||||
doi = {10.1016/j.jss.2021.111208},
|
||||
urldate = {2023-06-06},
|
||||
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.},
|
||||
archiveprefix = {arxiv},
|
||||
keywords = {{Computer Science - Distributed, Parallel, and Cluster Computing},Computer Science - Networking and Internet Architecture,Electrical Engineering and Systems Science - Systems and Control},
|
||||
file = {/home/amaury/Zotero/storage/K3LQZLC8/Somasekaram et al. - 2022 - High-Availability Clusters A Taxonomy, Survey, an.pdf;/home/amaury/Zotero/storage/B4KCP9BG/2109.html}
|
||||
}
|
||||
|
||||
@inproceedings{TsengDistributed2019,
|
||||
title = {Distributed {{Causal Memory}} in the {{Presence}} of {{Byzantine Servers}}},
|
||||
booktitle = {{{IEEE}} 18th {{International Symposium}} on {{Network Computing}} and {{Applications}} ({{NCA}})},
|
||||
author = {Tseng, Lewis and Wang, Zezhi and Zhao, Yajie and Pan, Haochen},
|
||||
year = {2019},
|
||||
month = sep,
|
||||
pages = {1--8},
|
||||
issn = {2643-7929},
|
||||
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.},
|
||||
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 = {/home/amaury/Zotero/storage/DDV34ULW/8935059.html}
|
||||
}
|
||||
|
||||
@article{VanDerLindePractical2020,
|
||||
title = {Practical Client-Side Replication: Weak Consistency Semantics for Insecure Settings},
|
||||
shorttitle = {Practical Client-Side Replication},
|
||||
author = {Van Der Linde, Albert and Leit{\~a}o, Jo{\~a}o and Pregui{\c c}a, Nuno},
|
||||
year = {2020},
|
||||
month = aug,
|
||||
journal = {Proceedings of the VLDB Endowment},
|
||||
volume = {13},
|
||||
number = {12},
|
||||
pages = {2590--2605},
|
||||
issn = {2150-8097},
|
||||
doi = {10.14778/3407790.3407847},
|
||||
urldate = {2023-06-06},
|
||||
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.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/5TJ3SA56/Van Der Linde et al. - 2020 - Practical client-side replication weak consistenc.pdf}
|
||||
}
|
||||
|
||||
@article{YanFlexible2017,
|
||||
title = {Flexible {{Data Access Control Based}} on {{Trust}} and {{Reputation}} in {{Cloud Computing}}},
|
||||
author = {Yan, Zheng and Li, Xueyun and Wang, Mingjun and Vasilakos, Athanasios V.},
|
||||
year = {2017},
|
||||
month = jul,
|
||||
journal = {IEEE Transactions on Cloud Computing},
|
||||
volume = {5},
|
||||
number = {3},
|
||||
pages = {485--498},
|
||||
issn = {2168-7161},
|
||||
doi = {10.1109/TCC.2015.2469662},
|
||||
urldate = {2023-12-08},
|
||||
abstract = {Cloud computing offers a new way of services and has become a popular service platform. Storing user data at a cloud data center greatly releases storage burden of user devices and brings access convenience. Due to distrust in cloud service providers, users generally store their crucial data in an encrypted form. But in many cases, the data need to be accessed by other entities for fulfilling an expected service, e.g., an eHealth service. How to control personal data access at cloud is a critical issue. Various application scenarios request flexible control on cloud data access based on data owner policies and application demands. Either data owners or some trusted third parties or both should flexibly participate in this control. However, existing work hasn't yet investigated an effective and flexible solution to satisfy this demand. On the other hand, trust plays an important role in data sharing. It helps overcoming uncertainty and avoiding potential risks. But literature still lacks a practical solution to control cloud data access based on trust and reputation. In this paper, we propose a scheme to control data access in cloud computing based on trust evaluated by the data owner and/or reputations generated by a number of reputation centers in a flexible manner by applying Attribue-Based Encryption and Proxy Re-Encryption. We integrate the concept of context-aware trust and reputation evaluation into a cryptographic system in order to support various control scenarios and strategies. The security and performance of our scheme are evaluated and justified through extensive analysis, security proof, comparison and implementation. The results show the efficiency, flexibility and effectiveness of our scheme for data access control in cloud computing.},
|
||||
langid = {english},
|
||||
file = {/home/amaury/Zotero/storage/EGDZNP8U/Yan et al. - 2017 - Flexible Data Access Control Based on Trust and Re.pdf}
|
||||
}
|
||||
|
||||
|
||||
@misc{Yjs2023,
|
||||
title = {Yjs/yjs: Shared data types for building collaborative software},
|
||||
year = {2023},
|
||||
month = dec,
|
||||
urldate = {2023-12-10},
|
||||
abstract = {Shared data types for building collaborative software},
|
||||
howpublished= {https://github.com/yjs/yjs},
|
||||
keywords = {collaboration,collaborative-editing,crdt,decentralized,offline-first,p2p,peer-to-peer,realtime,shared-editing,yjs}
|
||||
}
|
||||
380
docs/sujetThese/sujet-cifre.tex
Normal file
380
docs/sujetThese/sujet-cifre.tex
Normal file
@ -0,0 +1,380 @@
|
||||
\documentclass[11pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{paralist} %% needed for compact lists
|
||||
\usepackage[normalem]{ulem} %% needed by strike
|
||||
\usepackage[urlcolor=blue,colorlinks=true,breaklinks]{hyperref}
|
||||
\usepackage[utf8x]{inputenc} %% char encoding
|
||||
\usepackage{framed} %% frame multipages
|
||||
\usepackage{fullpage}
|
||||
\usepackage{a4wide}
|
||||
\usepackage{mathpazo} %% math & rm
|
||||
\linespread{1.05} %% Palatino needs more leading (space between lines)
|
||||
\usepackage[scaled]{helvet} %% ss
|
||||
\usepackage{courier} %% tt
|
||||
\normalfont
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage[english]{babel} %% en englais
|
||||
\usepackage{xspace} %% gestion des espaces après une macro
|
||||
\usepackage{listings}
|
||||
\lstset{breaklines}
|
||||
\lstset{language=java}
|
||||
\lstset{escapechar=§}
|
||||
\usepackage{xcolor}
|
||||
|
||||
|
||||
\usepackage{comment} %%%% comment env
|
||||
|
||||
%%%%%%%%%%%%%%
|
||||
%% fancy et brouillon
|
||||
%% Date en haut de page
|
||||
%% A commenter pour la version finale
|
||||
\usepackage[margin=2.5cm]{geometry}
|
||||
\usepackage{fancyhdr}
|
||||
%% Header and footer
|
||||
\fancyhf{} %%clear head and footer
|
||||
\fancyhead[C]{\thepage} %%draft
|
||||
\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
|
||||
\fancyfoot[C]{\textsc{SUJETCOURT}}
|
||||
\fancypagestyle{premiere}{%% première page
|
||||
\fancyhf{} %%clear head and footer
|
||||
\fancyfoot[L]{\textbf{LIF}}
|
||||
\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
|
||||
\fancyfoot[C]{\textsc{SUJETCOURT}}
|
||||
\fancyhead[C]{}%%\includegraphics[scale=0.25]{logo-lif.png}} %%UFR
|
||||
}
|
||||
\fancypagestyle{notete}{%% première page
|
||||
\fancyhf{} %%clear head and footer
|
||||
\renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{2pt}
|
||||
\fancyfoot[C]{\textsc{Sujet}}
|
||||
}
|
||||
|
||||
\newcommand{\myversion}{\textit{version du \today{}}}
|
||||
|
||||
\pagestyle{plain}
|
||||
|
||||
\title{Weak Consistency for zero-trust cloud}
|
||||
\author{Research Subject}
|
||||
\begin{document}
|
||||
|
||||
\date{Emmanuel Godard (LIS) -- Corentin Travers (LIS)\\emmanuel.godard@lis-lab.fr et corentin.travers@lis-lab.fr}
|
||||
\maketitle
|
||||
|
||||
\textbf{Keywords:} Cloud, Security by design, Distributed Structures and Algorithms, Weak Consistencies, Byzantine systems
|
||||
|
||||
\section*{Summary}
|
||||
|
||||
Real-time collaborative applications are increasingly utilized in the context
|
||||
of remote work systems. These applications often rely on centralized client-server
|
||||
architectures, which pose security and privacy challenges. Data is stored on a
|
||||
centralized server, requiring users to trust a third party with their data management.
|
||||
Additionally, these architectures are often vulnerable to denial-of-service attacks
|
||||
and do not ensure data confidentiality.
|
||||
|
||||
To address these issues, we propose exploring information exchange solutions based
|
||||
on zero-trust and/or peer-to-peer architectures that eliminate the need for trusted
|
||||
third parties. These solutions would offer high-level security while ensuring system
|
||||
resilience. To maintain strong performance, especially in high availability scenarios,
|
||||
weak consistency models are frequently employed.
|
||||
|
||||
In this context, we propose studying weak consistency properties applied to
|
||||
cloud-related challenges. Initially, we will conduct a state-of-the-art review of
|
||||
Byzantine fault-tolerant solutions without cryptographic primitives, along with
|
||||
existing implementations (WP1). A second step will involve proposing more efficient
|
||||
solutions using cryptographic primitives (WP2). Finally, a proof-of-concept will be
|
||||
developed for a key-value storage solution using the algorithms selected in the
|
||||
previous stages (WP3).
|
||||
|
||||
\pagebreak
|
||||
|
||||
\section*{Problematic}
|
||||
|
||||
Since the pioneering work in the 1980s by Lamport \cite{LamportInterprocess1986}
|
||||
and Misra \cite{MisraAxioms1986}, replication management has been central to digital
|
||||
developments in terms of high availability. One of the fundamental challenges is
|
||||
to provide application developers with an abstraction of replicated memory that is
|
||||
both easy to use and enables flexible and fault-tolerant utilization of distributed resources.
|
||||
|
||||
This line of research has led to the concept of \textit{data consistency}, with its
|
||||
various forms tailored to suit the best compromises in usage and specificities of each application.
|
||||
|
||||
The current trend towards cloud-based deployment of software applications entails significant
|
||||
changes in usage patterns and development approaches for new applications. With the advent
|
||||
of user-friendly cloud services where infrastructure maintenance is outsourced to a provider,
|
||||
there's a noticeable centralization of resources. This reintroduces classic security issues,
|
||||
such as the need for trust/sovereignty or the risk of a \textit{single point of failure} (SPOF).
|
||||
|
||||
In response, new approaches termed \textit{zero-trust} have been proposed to continue using
|
||||
cloud resources without depending on any specific provider. These approaches require both
|
||||
multi-provider architectures and advanced cryptographic techniques.
|
||||
|
||||
\medskip
|
||||
|
||||
From a programmer's perspective, it's often advantageous to consider cloud-based applications
|
||||
as a single centralized system. This requires that the data structures used exhibit a
|
||||
property known as \textit{strong consistency}.
|
||||
|
||||
In real-world conditions, servers may have to endure very challenging operating conditions.
|
||||
It is well-known to both theorists and practitioners, through the CAP theorem
|
||||
(Consistency, Availability, Partition tolerance), that operational compromises are often
|
||||
necessary. Specifically, if strong consistency is desired, the computation time is proportional
|
||||
to the latency of \textbf{the entire} network, which in practice reduces availability.
|
||||
|
||||
Referring to the CAP theorem, applying strong consistency makes it impossible to implement
|
||||
a highly resilient system while providing a highly available application. Yet, both of
|
||||
these aspects can be essential in building a collaborative application.
|
||||
|
||||
The peer-to-peer approach indeed implies significant system resilience against failures.
|
||||
Replicas may become disconnected from one another and experience significant and uneven latency
|
||||
differences. The lack of control over the client's system and execution environment compels
|
||||
us to envision systems capable of withstanding the worst possible scenarios.
|
||||
|
||||
In the context of real-time collaboration applications, the need for high availability is
|
||||
intimately tied to the requirement of enabling different replicas to access the same
|
||||
shared data for real-time work. It would therefore be unacceptable to introduce significant
|
||||
latencies between two modifications.
|
||||
|
||||
Given the impossibility of fully satisfying both strong consistency and high availability,
|
||||
we turn to the study of weak consistencies, specifically focusing on convergence. We define
|
||||
a system as convergent if it adheres to the following property:
|
||||
|
||||
If replicas cease to propose modifications, then these same replicas must eventually
|
||||
reach a consistent state.
|
||||
|
||||
Convergence (or Eventual Consistency) has been extensively studied, leading to the development
|
||||
of various distributed data structures that aim to uphold convergence. However, convergence
|
||||
alone does not resolve our problem. This property does not guarantee behaviors during execution,
|
||||
where inconsistency within the system is permissible due to convergence. Simply achieving
|
||||
eventual consistency in a document does not suffice to make it a satisfactory collaborative
|
||||
editing application. We also need mechanisms to resolve conflicts, which are inevitable in
|
||||
collaborative approaches. This conflict resolution must be carried out optimally to maximize
|
||||
the preservation of the meaning intended by each modifying replica.
|
||||
|
||||
These issues have indeed been extensively studied, and the solutions proposed, particularly
|
||||
suitable in our context, are the \textit{Replicated Data Types} (RDTs). There are two classes of RDTs:
|
||||
|
||||
Commutative Replicated Data Types (CmRDTs): Operations on these types yield the same result
|
||||
regardless of the order of their local executions.
|
||||
|
||||
Convergent Replicated Data Types (CvRDTs): These types, for example, a system where data aims
|
||||
to continuously grow, converge towards a maximal structure.
|
||||
|
||||
Both classes fall under the umbrella term of Conflict-free Replicated Data Types (CRDTs) and are
|
||||
actually equivalent to each other \cite{ShapiroConflictFree2011}.
|
||||
CRDTs provide a powerful framework for building distributed applications that require high availability
|
||||
and eventual consistency. By ensuring that operations are commutative and can be merged across
|
||||
eplicas without conflicts, CRDTs enable efficient conflict resolution and convergence of data
|
||||
across distributed systems.
|
||||
The study of CRDTs has significantly advanced our ability to design collaborative and resilient
|
||||
distributed applications, offering a practical approach to dealing with the challenges posed by real-time
|
||||
collaboration over unreliable and latency-prone networks.
|
||||
|
||||
\medskip
|
||||
|
||||
Furthermore, to provide truly secure solutions in a zero-trust context, the most challenging operational
|
||||
conditions to consider are when servers or participating clients have been compromised and do not
|
||||
strictly adhere to the protocol. In the literature, this is referred to as Byzantine behavior.
|
||||
|
||||
Given these difficult constraints of availability and security, ensuring strong consistency can be
|
||||
very computationally and time-intensive. Application requirements are sometimes not compatible with
|
||||
such operational conditions. Therefore, it becomes necessary to consider data with properties of
|
||||
so-called \textit{weak consistency}.
|
||||
|
||||
Weak consistency models, such as eventual consistency offered by CRDTs, become valuable in such scenarios.
|
||||
These models prioritize availability and partition tolerance while allowing for some degree of
|
||||
inconsistency that can be resolved over time. They are designed to cope with the challenges of distributed
|
||||
systems operating under non-ideal conditions, including the presence of Byzantine faults.
|
||||
|
||||
In zero-trust environments where malicious behaviors are a constant threat, adopting weak consistency models
|
||||
can strike a balance between functionality, security, and operational feasibility. They provide pragmatic
|
||||
solutions for building resilient and secure distributed applications that can withstand the challenges posed
|
||||
by compromised nodes and unreliable network conditions.
|
||||
|
||||
\section*{State of the art}
|
||||
|
||||
The landscape of weak consistency properties is relatively complex, with three major families of weak
|
||||
consistencies identified \cite{Raynal18}, \cite{MPBook}:
|
||||
|
||||
\begin{itemize}
|
||||
\item Serializability
|
||||
\item Causal Consistency
|
||||
\item Eventual Strong Consistency
|
||||
\end{itemize}
|
||||
|
||||
While eventual strong consistency is typically desired for collaborative applications, it is particularly
|
||||
costly to achieve. Serializability, on the other hand, is simpler to implement but may result in transactions
|
||||
that do not complete, requiring application-level error handling.
|
||||
|
||||
Causal consistency maintains the causal order perceived by each process and generally allows for the efficient
|
||||
implementation of higher-level data structures.
|
||||
|
||||
For a comprehensive overview of these weak consistency models, readers can refer to M. Perrin's detailed
|
||||
mapping \cite{MPBook}. Each of these models offers a different trade-off between consistency guarantees,
|
||||
implementation complexity, and operational efficiency, making them suitable for different use cases and
|
||||
application requirements. Understanding and selecting the appropriate weak consistency model is crucial for
|
||||
designing effective and robust distributed systems, especially in the context of collaborative applications
|
||||
operating in dynamic and unreliable environments.
|
||||
|
||||
\subsection*{Algorithmic Results}
|
||||
|
||||
The earliest work on secure collaborative tools in a high availability context dates back to 2009; however,
|
||||
more systematic research on weak consistency security is quite recent. In 2009, Sing et al. introduced the
|
||||
Zeno system, which was the first to propose a Byzantine algorithm favoring availability over strong consistency.
|
||||
It provides Byzantine fault tolerance with potentially strong consistency \cite{SinghZeno2009}. The algorithm
|
||||
experimentally demonstrated better availability performance compared to classical Byzantine algorithms.
|
||||
|
||||
Currently, there are primarily partial studies and solutions for causal consistency \cite{TsengDistributed2019}
|
||||
and \cite{VanDerLindePractical2020}. Tseng et al. present exact computability bounds within a Byzantine
|
||||
framework on one hand and provide an algorithm whose performance is compared with that of the Google Compute
|
||||
platform. Van Der Linde et al. introduce a peer-to-peer system resilient to Byzantine attacks that offers causal
|
||||
consistency guarantees. Their evaluation suggests that despite a peer-to-peer architecture, performance, especially
|
||||
in terms of latency, is very good compared to a traditional client-server architecture.
|
||||
|
||||
In addition to these algorithms, Misra and Kshemkalyani demonstrated in \cite{MisraByzantine2021} that in an
|
||||
asynchronous context, it is not possible to achieve causal consistency even with a single Byzantine participant.
|
||||
|
||||
One of the notable features of \cite{VanDerLindePractical2020} is its exploration of Byzantine failures within
|
||||
the context of weak consistencies. A peer-to-peer system like that in \cite{MisraByzantine2021} prompts new
|
||||
considerations where a participant leverages information from lower layers of replication to create attacks at
|
||||
the application level.
|
||||
|
||||
Applying weak consistency criteria alone doesn't fully address the scope of our concerns. The cloud context
|
||||
raises significant questions regarding data centralization and governance, with a market dominated by a few
|
||||
major players to whom users must blindly entrust their data, posing substantial challenges to privacy and data
|
||||
sovereignty.
|
||||
|
||||
In this context, integrating the notion of a zero-trust cloud is essential, anchoring our discussions in a
|
||||
relevant approach from both industrial and regulatory perspectives. Zero-trust, as defined by NIST in SP 800-207
|
||||
\cite{RoseZero2020}, is a security model that trusts no one and makes no assumptions about network security. It
|
||||
helps guard against malicious behaviors by intermediaries, reducing the attack surface and confining Byzantine
|
||||
behaviors solely to clients who have access to the data.
|
||||
|
||||
Certainly, the consideration of data-centric security alongside communication security is crucial. Adopting
|
||||
"Data-Centric" approaches involves treating data itself as a dynamic entity within the system, assigning it
|
||||
processes for access control and monitoring \cite{BayukDatacentric2009}. These issues represent growing concerns
|
||||
and are addressed by state and inter-state actors, exemplified by NATO's stance on these matters through
|
||||
STANAG 4774 and 4778. These topics have been extensively studied since the 2010s with works such as
|
||||
\cite{GoyalAttributebased2006, MullerDistributed2009} defining solutions for attribute-based encryption,
|
||||
issuing encryption keys based on rights to establish security policies. Other works like \cite{YanFlexible2017}
|
||||
propose cloud-adapted solutions based on more flexible architectures with finer granularity in defining rights.
|
||||
|
||||
However, concerning zero-trust and data-centric security aspects, there is currently no academic consensus
|
||||
on the formalization of these notions. These terms are subject to various interpretations, necessitating a
|
||||
formal specification to understand which properties need to be satisfied to achieve weak consistency within
|
||||
a zero-trust context.
|
||||
|
||||
\subsection*{Existing Implementations}
|
||||
|
||||
Currently, there are ongoing projects aimed at implementing weak consistency protocols for real-time collaborative
|
||||
applications. One notable project is yjs \cite{Yjs2023}, which implements the YATA protocol \cite{NicolaescuRealTime2016}.
|
||||
This protocol ensures strong convergence (or SEC, according to the Perrin reference) through a CRDT
|
||||
(Conflict-free Replicated Data Type) system.
|
||||
|
||||
On the other hand, older projects like Etherpad use simpler conflict resolution solutions, also ensuring strong
|
||||
convergence but employing more complex algorithmic operations in terms of memory and computation time compared
|
||||
to CRDTs \cite{AppJetEtherpad2011}.
|
||||
|
||||
\section*{Goals}
|
||||
|
||||
The objectives of this thesis encompass studying the three types of weak consistency in a Byzantine setting and
|
||||
defining efficient Byzantine algorithms for their implementation. Given that causal consistency is already well-studied,
|
||||
the main focus of this thesis will be on the other two types of weak consistency.
|
||||
|
||||
The first stage (WP1) will involve studying Byzantine solutions without cryptographic primitives or with reasonably
|
||||
cost-effective primitives, specifically excluding homomorphic computation. An analysis of existing implementations will
|
||||
be conducted to determine the guarantees provided by these solutions within the vocabulary of weak consistencies.
|
||||
|
||||
The second stage (WP2) will focus on developing more efficient solutions using cryptographic primitives that require
|
||||
advanced secret-sharing and/or homomorphic computation.
|
||||
|
||||
A final stage (WP3) will involve producing a proof-of-concept key/value storage solution using the algorithms
|
||||
selected in the preceding stages.
|
||||
|
||||
\section*{Methodology and Planning}
|
||||
|
||||
A detailed review of distributed computing models, particularly focusing on solutions for causal consistency,
|
||||
will be conducted to establish the set of theoretical and practical assumptions underlying these solutions.
|
||||
Concurrently, in collaboration with Parsec, a list of attacks on weakly consistent peer-to-peer architectures
|
||||
will be compiled. The emphasis will be on generating new knowledge, including novel solutions compared to the
|
||||
current state of the art, as well as identifying new attack vectors.
|
||||
|
||||
The algorithms will undergo formal validation initially, followed by the development of a proof of concept.
|
||||
|
||||
WP1 will take place in 2024, WP2 in 2025, and WP3 in ZO26.
|
||||
|
||||
\section*{Monitoring and Exchange Terms}
|
||||
|
||||
Le doctorant participe aux réunions hebdomadaires de suivi de
|
||||
l'entreprise Parsec. Les partenaires se rencontreront tous les trois
|
||||
mois pour un point d'avancée sur les travaux.
|
||||
|
||||
Il participera également aux réunions physiques de
|
||||
l'entreprise tous les 6 mois.
|
||||
|
||||
\section*{Material resources}
|
||||
|
||||
The Phd student will participate in Parsec's weekly progress meetings. Additionally, partners will convene
|
||||
every three months for project status updates.
|
||||
|
||||
Furthermore, the student will attend in-person meetings at the company every six months.
|
||||
|
||||
\section*{Expected Benefits}
|
||||
|
||||
On the LIS laboratory side, the expected outcomes include the following scientific publications:
|
||||
|
||||
\begin{compactitem}
|
||||
\item State-of-the-art review and synthesis concerning Byzantine fault tolerance in weak consistencies.
|
||||
\item Proposals and proofs of new algorithms within the zero-trust context.
|
||||
\end{compactitem}
|
||||
|
||||
For Parsec, the expected deliverables comprise a mini-model of cloud synchronization and collaboration,
|
||||
a proof of concept for the aforementioned algorithms, and consultancy and expertise in the scientific
|
||||
development of products created by Parsec.
|
||||
|
||||
\section*{Team}
|
||||
|
||||
\subsection*{Distributed Algorithmics Team (DALGO)}
|
||||
|
||||
The Distributed Algorithms team, led by Arnaud Labourel, is part of the Laboratory of Computer
|
||||
Science and Systems (LIS CNRS UMR 7020). This research team is internationally recognized at the
|
||||
highest level, comprising 8 permanent members whose interests span from reliable distributed
|
||||
algorithms and confidentiality in distributed systems to communication networks, graph algorithms,
|
||||
mobile agents, and IoT (Internet of Things).
|
||||
|
||||
\subsection*{Supervisors}
|
||||
|
||||
\textbf{Emmanuel Godard} is a professor at Aix-Marseille University. His research interests
|
||||
primarily focus on understanding and maximizing decentralization (in a broad sense) in
|
||||
distributed systems. He is an expert in distributed algorithms and computability.
|
||||
|
||||
\textbf{Corentin Travers} is an Associate Professor at Aix-Marseille University. His research
|
||||
interests focus on robust and efficient distributed algorithms for shared-memory systems or
|
||||
distributed networks. He is an expert in distributed algorithmics and complexity.
|
||||
|
||||
\textbf{Marcos Medrano} is an R\&D engineer at Parsec. He holds a master's degree in research
|
||||
in computer science and applied mathematics. Marcos is responsible for the development
|
||||
strategy of the Parsec product and facilitates collaboration between engineers and academic stakeholders.
|
||||
|
||||
\subsection*{Candidate Choice}
|
||||
|
||||
The DALGO team is involved in the "Reliability and Computer Security" Master's program at Aix-Marseille
|
||||
University. This master's track is certified as \textit{SecNumEdu} by ANSSI
|
||||
(National Cybersecurity Agency of France). In autumn 2022, a project in collaboration with the company
|
||||
Parsec was presented to all master's students. Following this call for applications, Mr. Amaury Joly
|
||||
was selected for a preliminary 6-month research internship on the topic of weak consistency at the
|
||||
LIS laboratory.
|
||||
|
||||
Mr. Amaury Joly has achieved excellent academic results, earning a good mention in the master's
|
||||
program. Additionally, he possesses a strong dual theoretical and technical profile, with a keen
|
||||
motivation for research activities related to cloud security. He is the ideal candidate for such
|
||||
a research topic.
|
||||
|
||||
{\footnotesize
|
||||
\nocite{*}
|
||||
|
||||
\bibliography{sujet-cifre.bib}
|
||||
\bibliographystyle{alpha}
|
||||
}
|
||||
|
||||
% LaTeX2e code generated by txt2tags 3.4 (http://txt2tags.org)
|
||||
% cmdline: txt2tags -t tex sujet-cifre.t2t
|
||||
\end{document}
|
||||
43
out/docs/rapport/rapport_etat_art/images/local1/local1.latex
Normal file
43
out/docs/rapport/rapport_etat_art/images/local1/local1.latex
Normal file
@ -0,0 +1,43 @@
|
||||
% generated by Plantuml 1.2022.7
|
||||
\definecolor{plantucolor0000}{RGB}{24,24,24}
|
||||
\definecolor{plantucolor0001}{RGB}{0,0,0}
|
||||
\definecolor{plantucolor0002}{RGB}{226,226,240}
|
||||
\begin{tikzpicture}[yscale=-1
|
||||
,pstyle0/.style={color=plantucolor0000,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
|
||||
,pstyle1/.style={color=plantucolor0000,fill=plantucolor0002,line width=0.5pt}
|
||||
,pstyle3/.style={color=plantucolor0000,fill=plantucolor0000,line width=1.0pt}
|
||||
,pstyle4/.style={color=plantucolor0000,line width=1.0pt}
|
||||
]
|
||||
\draw[pstyle0] (23pt,84.0679pt) -- (23pt,311.01pt);
|
||||
\draw[pstyle0] (134.7162pt,84.0679pt) -- (134.7162pt,311.01pt);
|
||||
\draw[pstyle0] (208.3289pt,84.0679pt) -- (208.3289pt,311.01pt);
|
||||
\draw[pstyle0] (368.0101pt,84.0679pt) -- (368.0101pt,311.01pt);
|
||||
\node at (5pt,65pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle1] (23.3692pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[color=plantucolor0000,line width=0.5pt] (23.3692pt,21.5pt) -- (23.3692pt,48.5pt)(10.3692pt,29.5pt) -- (36.3692pt,29.5pt)(23.3692pt,48.5pt) -- (10.3692pt,63.5pt)(23.3692pt,48.5pt) -- (36.3692pt,63.5pt);
|
||||
\draw[pstyle1] (100.7162pt,55pt) arc (180:270:5pt) -- (105.7162pt,50pt) -- (164.3289pt,50pt) arc (270:360:5pt) -- (169.3289pt,55pt) -- (169.3289pt,78.0679pt) arc (0:90:5pt) -- (164.3289pt,83.0679pt) -- (105.7162pt,83.0679pt) arc (90:180:5pt) -- (100.7162pt,78.0679pt) -- cycle;
|
||||
\node at (107.7162pt,57pt)[below right,color=black]{Clavier};
|
||||
\draw[pstyle1] (179.3289pt,55pt) arc (180:270:5pt) -- (184.3289pt,50pt) -- (233.3289pt,50pt) arc (270:360:5pt) -- (238.3289pt,55pt) -- (238.3289pt,78.0679pt) arc (0:90:5pt) -- (233.3289pt,83.0679pt) -- (184.3289pt,83.0679pt) arc (90:180:5pt) -- (179.3289pt,78.0679pt) -- cycle;
|
||||
\node at (186.3289pt,57pt)[below right,color=black]{Ecran};
|
||||
\draw[pstyle1] (330.0101pt,55pt) arc (180:270:5pt) -- (335.0101pt,50pt) -- (402.2546pt,50pt) arc (270:360:5pt) -- (407.2546pt,55pt) -- (407.2546pt,78.0679pt) arc (0:90:5pt) -- (402.2546pt,83.0679pt) -- (335.0101pt,83.0679pt) arc (90:180:5pt) -- (330.0101pt,78.0679pt) -- cycle;
|
||||
\node at (337.0101pt,57pt)[below right,color=black]{Système};
|
||||
\draw[pstyle3] (123.0226pt,113.7739pt) -- (133.0226pt,117.7739pt) -- (123.0226pt,121.7739pt) -- (127.0226pt,117.7739pt) -- cycle;
|
||||
\draw[pstyle4] (23.3692pt,117.7739pt) -- (129.0226pt,117.7739pt);
|
||||
\node at (30.3692pt,98.0679pt)[below right,color=black]{Ecrit "Hello"};
|
||||
\draw[pstyle3] (356.6323pt,145.4799pt) -- (366.6323pt,149.4799pt) -- (356.6323pt,153.4799pt) -- (360.6323pt,149.4799pt) -- cycle;
|
||||
\draw[pstyle4] (135.0226pt,149.4799pt) -- (362.6323pt,149.4799pt);
|
||||
\node at (142.0226pt,129.7739pt)[below right,color=black]{Envoie "Hello"};
|
||||
\draw[pstyle4] (368.6323pt,198.892pt) -- (410.6323pt,198.892pt);
|
||||
\draw[pstyle4] (410.6323pt,198.892pt) -- (410.6323pt,211.892pt);
|
||||
\draw[pstyle4] (369.6323pt,211.892pt) -- (410.6323pt,211.892pt);
|
||||
\draw[pstyle3] (379.6323pt,207.892pt) -- (369.6323pt,211.892pt) -- (379.6323pt,215.892pt) -- (375.6323pt,211.892pt) -- cycle;
|
||||
\node at (375.6323pt,161.4799pt)[below right,color=black]{Accepte la saisie et};
|
||||
\node at (375.6323pt,179.186pt)[below right,color=black]{modifie le document};
|
||||
\draw[pstyle3] (219.8289pt,257.304pt) -- (209.8289pt,261.304pt) -- (219.8289pt,265.304pt) -- (215.8289pt,261.304pt) -- cycle;
|
||||
\draw[pstyle4] (213.8289pt,261.304pt) -- (367.6323pt,261.304pt);
|
||||
\node at (225.8289pt,223.892pt)[below right,color=black]{Afiche le document};
|
||||
\node at (225.8289pt,241.598pt)[below right,color=black]{mis à jour};
|
||||
\draw[pstyle3] (34.3692pt,289.01pt) -- (24.3692pt,293.01pt) -- (34.3692pt,297.01pt) -- (30.3692pt,293.01pt) -- cycle;
|
||||
\draw[pstyle4] (28.3692pt,293.01pt) -- (207.8289pt,293.01pt);
|
||||
\node at (40.3692pt,273.304pt)[below right,color=black]{Regarde};
|
||||
\end{tikzpicture}
|
||||
64
out/docs/rapport/rapport_etat_art/images/local2/local1.latex
Normal file
64
out/docs/rapport/rapport_etat_art/images/local2/local1.latex
Normal file
@ -0,0 +1,64 @@
|
||||
% generated by Plantuml 1.2022.7
|
||||
\definecolor{plantucolor0000}{RGB}{24,24,24}
|
||||
\definecolor{plantucolor0001}{RGB}{0,0,0}
|
||||
\definecolor{plantucolor0002}{RGB}{226,226,240}
|
||||
\begin{tikzpicture}[yscale=-1
|
||||
,pstyle0/.style={color=plantucolor0000,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
|
||||
,pstyle1/.style={color=plantucolor0000,fill=plantucolor0002,line width=0.5pt}
|
||||
,pstyle2/.style={color=plantucolor0000,line width=0.5pt}
|
||||
,pstyle3/.style={color=plantucolor0000,fill=plantucolor0000,line width=1.0pt}
|
||||
,pstyle4/.style={color=plantucolor0000,line width=1.0pt}
|
||||
]
|
||||
\draw[pstyle0] (23pt,84.0679pt) -- (23pt,456.5401pt);
|
||||
\draw[pstyle0] (72.7385pt,84.0679pt) -- (72.7385pt,456.5401pt);
|
||||
\draw[pstyle0] (142.6385pt,84.0679pt) -- (142.6385pt,456.5401pt);
|
||||
\draw[pstyle0] (230.3112pt,84.0679pt) -- (230.3112pt,456.5401pt);
|
||||
\draw[pstyle0] (308.9839pt,84.0679pt) -- (308.9839pt,456.5401pt);
|
||||
\draw[pstyle0] (468.6651pt,84.0679pt) -- (468.6651pt,456.5401pt);
|
||||
\node at (5pt,65pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle1] (23.3692pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[pstyle2] (23.3692pt,21.5pt) -- (23.3692pt,48.5pt)(10.3692pt,29.5pt) -- (36.3692pt,29.5pt)(23.3692pt,48.5pt) -- (10.3692pt,63.5pt)(23.3692pt,48.5pt) -- (36.3692pt,63.5pt);
|
||||
\node at (51.7385pt,65pt)[below right,color=black]{Alice};
|
||||
\draw[pstyle1] (73.1885pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[pstyle2] (73.1885pt,21.5pt) -- (73.1885pt,48.5pt)(60.1885pt,29.5pt) -- (86.1885pt,29.5pt)(73.1885pt,48.5pt) -- (60.1885pt,63.5pt)(73.1885pt,48.5pt) -- (86.1885pt,63.5pt);
|
||||
\draw[pstyle1] (104.6385pt,55pt) arc (180:270:5pt) -- (109.6385pt,50pt) -- (177.3112pt,50pt) arc (270:360:5pt) -- (182.3112pt,55pt) -- (182.3112pt,78.0679pt) arc (0:90:5pt) -- (177.3112pt,83.0679pt) -- (109.6385pt,83.0679pt) arc (90:180:5pt) -- (104.6385pt,78.0679pt) -- cycle;
|
||||
\node at (111.6385pt,57pt)[below right,color=black]{Clavier1};
|
||||
\draw[pstyle1] (192.3112pt,55pt) arc (180:270:5pt) -- (197.3112pt,50pt) -- (264.9839pt,50pt) arc (270:360:5pt) -- (269.9839pt,55pt) -- (269.9839pt,78.0679pt) arc (0:90:5pt) -- (264.9839pt,83.0679pt) -- (197.3112pt,83.0679pt) arc (90:180:5pt) -- (192.3112pt,78.0679pt) -- cycle;
|
||||
\node at (199.3112pt,57pt)[below right,color=black]{Clavier2};
|
||||
\draw[pstyle1] (279.9839pt,55pt) arc (180:270:5pt) -- (284.9839pt,50pt) -- (333.9839pt,50pt) arc (270:360:5pt) -- (338.9839pt,55pt) -- (338.9839pt,78.0679pt) arc (0:90:5pt) -- (333.9839pt,83.0679pt) -- (284.9839pt,83.0679pt) arc (90:180:5pt) -- (279.9839pt,78.0679pt) -- cycle;
|
||||
\node at (286.9839pt,57pt)[below right,color=black]{Ecran};
|
||||
\draw[pstyle1] (430.6651pt,55pt) arc (180:270:5pt) -- (435.6651pt,50pt) -- (502.9095pt,50pt) arc (270:360:5pt) -- (507.9095pt,55pt) -- (507.9095pt,78.0679pt) arc (0:90:5pt) -- (502.9095pt,83.0679pt) -- (435.6651pt,83.0679pt) arc (90:180:5pt) -- (430.6651pt,78.0679pt) -- cycle;
|
||||
\node at (437.6651pt,57pt)[below right,color=black]{Système};
|
||||
\draw[pstyle3] (131.4748pt,113.7739pt) -- (141.4748pt,117.7739pt) -- (131.4748pt,121.7739pt) -- (135.4748pt,117.7739pt) -- cycle;
|
||||
\draw[pstyle4] (23.3692pt,117.7739pt) -- (137.4748pt,117.7739pt);
|
||||
\node at (30.3692pt,98.0679pt)[below right,color=black]{Ecrit "Hello"};
|
||||
\draw[pstyle3] (457.2873pt,145.4799pt) -- (467.2873pt,149.4799pt) -- (457.2873pt,153.4799pt) -- (461.2873pt,149.4799pt) -- cycle;
|
||||
\draw[pstyle4] (143.4748pt,149.4799pt) -- (463.2873pt,149.4799pt);
|
||||
\node at (150.4748pt,129.7739pt)[below right,color=black]{Envoie "Hello"};
|
||||
\draw[pstyle3] (320.4839pt,194.892pt) -- (310.4839pt,198.892pt) -- (320.4839pt,202.892pt) -- (316.4839pt,198.892pt) -- cycle;
|
||||
\draw[pstyle4] (314.4839pt,198.892pt) -- (468.2873pt,198.892pt);
|
||||
\node at (326.4839pt,161.4799pt)[below right,color=black]{Afiche le document};
|
||||
\node at (326.4839pt,179.186pt)[below right,color=black]{mis à jour};
|
||||
\draw[pstyle3] (34.3692pt,226.598pt) -- (24.3692pt,230.598pt) -- (34.3692pt,234.598pt) -- (30.3692pt,230.598pt) -- cycle;
|
||||
\draw[pstyle4] (28.3692pt,230.598pt) -- (308.4839pt,230.598pt);
|
||||
\node at (40.3692pt,210.892pt)[below right,color=black]{Regarde "Hello"};
|
||||
\draw[pstyle3] (84.1885pt,258.304pt) -- (74.1885pt,262.304pt) -- (84.1885pt,266.304pt) -- (80.1885pt,262.304pt) -- cycle;
|
||||
\draw[pstyle4] (78.1885pt,262.304pt) -- (308.4839pt,262.304pt);
|
||||
\node at (90.1885pt,242.598pt)[below right,color=black]{Regarde "Hello"};
|
||||
\draw[pstyle3] (219.1476pt,290.01pt) -- (229.1476pt,294.01pt) -- (219.1476pt,298.01pt) -- (223.1476pt,294.01pt) -- cycle;
|
||||
\draw[pstyle4] (73.1885pt,294.01pt) -- (225.1476pt,294.01pt);
|
||||
\node at (80.1885pt,274.304pt)[below right,color=black]{Ecrit "World"};
|
||||
\draw[pstyle3] (457.2873pt,321.716pt) -- (467.2873pt,325.716pt) -- (457.2873pt,329.716pt) -- (461.2873pt,325.716pt) -- cycle;
|
||||
\draw[pstyle4] (231.1476pt,325.716pt) -- (463.2873pt,325.716pt);
|
||||
\node at (238.1476pt,306.01pt)[below right,color=black]{Envoie "World"};
|
||||
\draw[pstyle3] (320.4839pt,371.1281pt) -- (310.4839pt,375.1281pt) -- (320.4839pt,379.1281pt) -- (316.4839pt,375.1281pt) -- cycle;
|
||||
\draw[pstyle4] (314.4839pt,375.1281pt) -- (468.2873pt,375.1281pt);
|
||||
\node at (326.4839pt,337.716pt)[below right,color=black]{Afiche le document};
|
||||
\node at (326.4839pt,355.4221pt)[below right,color=black]{mis à jour};
|
||||
\draw[pstyle3] (34.3692pt,402.8341pt) -- (24.3692pt,406.8341pt) -- (34.3692pt,410.8341pt) -- (30.3692pt,406.8341pt) -- cycle;
|
||||
\draw[pstyle4] (28.3692pt,406.8341pt) -- (308.4839pt,406.8341pt);
|
||||
\node at (40.3692pt,387.1281pt)[below right,color=black]{Regarde "HelloWorld"};
|
||||
\draw[pstyle3] (84.1885pt,434.5401pt) -- (74.1885pt,438.5401pt) -- (84.1885pt,442.5401pt) -- (80.1885pt,438.5401pt) -- cycle;
|
||||
\draw[pstyle4] (78.1885pt,438.5401pt) -- (308.4839pt,438.5401pt);
|
||||
\node at (90.1885pt,418.8341pt)[below right,color=black]{Regarde "HelloWorld"};
|
||||
\end{tikzpicture}
|
||||
41
out/docs/rapport/rapport_etat_art/images/local2/local2.latex
Normal file
41
out/docs/rapport/rapport_etat_art/images/local2/local2.latex
Normal file
@ -0,0 +1,41 @@
|
||||
% generated by Plantuml 1.2022.7
|
||||
\definecolor{plantucolor0000}{RGB}{24,24,24}
|
||||
\definecolor{plantucolor0001}{RGB}{0,0,0}
|
||||
\definecolor{plantucolor0002}{RGB}{226,226,240}
|
||||
\begin{tikzpicture}[yscale=-1
|
||||
,pstyle0/.style={color=plantucolor0000,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
|
||||
,pstyle1/.style={color=plantucolor0000,fill=plantucolor0002,line width=0.5pt}
|
||||
,pstyle2/.style={color=plantucolor0000,line width=0.5pt}
|
||||
,pstyle3/.style={color=plantucolor0000,fill=plantucolor0000,line width=1.0pt}
|
||||
,pstyle4/.style={color=plantucolor0000,line width=1.0pt}
|
||||
]
|
||||
\draw[pstyle0] (26pt,84.0679pt) -- (26pt,294.304pt);
|
||||
\draw[pstyle0] (75.9pt,84.0679pt) -- (75.9pt,294.304pt);
|
||||
\draw[pstyle0] (235.9633pt,84.0679pt) -- (235.9633pt,294.304pt);
|
||||
\node at (5pt,65pt)[below right,color=black]{Alice};
|
||||
\draw[pstyle1] (26.45pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[pstyle2] (26.45pt,21.5pt) -- (26.45pt,48.5pt)(13.45pt,29.5pt) -- (39.45pt,29.5pt)(26.45pt,48.5pt) -- (13.45pt,63.5pt)(26.45pt,48.5pt) -- (39.45pt,63.5pt);
|
||||
\node at (57.9pt,65pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle1] (76.2692pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[pstyle2] (76.2692pt,21.5pt) -- (76.2692pt,48.5pt)(63.2692pt,29.5pt) -- (89.2692pt,29.5pt)(76.2692pt,48.5pt) -- (63.2692pt,63.5pt)(76.2692pt,48.5pt) -- (89.2692pt,63.5pt);
|
||||
\draw[pstyle1] (184.9633pt,55pt) arc (180:270:5pt) -- (189.9633pt,50pt) -- (282.623pt,50pt) arc (270:360:5pt) -- (287.623pt,55pt) -- (287.623pt,78.0679pt) arc (0:90:5pt) -- (282.623pt,83.0679pt) -- (189.9633pt,83.0679pt) arc (90:180:5pt) -- (184.9633pt,78.0679pt) -- cycle;
|
||||
\node at (191.9633pt,57pt)[below right,color=black]{Application};
|
||||
\draw[pstyle3] (224.2932pt,113.7739pt) -- (234.2932pt,117.7739pt) -- (224.2932pt,121.7739pt) -- (228.2932pt,117.7739pt) -- cycle;
|
||||
\draw[pstyle4] (26.45pt,117.7739pt) -- (230.2932pt,117.7739pt);
|
||||
\node at (33.45pt,98.0679pt)[below right,color=black]{saisir("Hello")};
|
||||
\draw[pstyle3] (37.45pt,145.4799pt) -- (27.45pt,149.4799pt) -- (37.45pt,153.4799pt) -- (33.45pt,149.4799pt) -- cycle;
|
||||
\draw[pstyle4] (31.45pt,149.4799pt) -- (235.2932pt,149.4799pt);
|
||||
\node at (43.45pt,129.7739pt)[below right,color=black]{lire("Hello")};
|
||||
\draw[pstyle3] (87.2692pt,177.186pt) -- (77.2692pt,181.186pt) -- (87.2692pt,185.186pt) -- (83.2692pt,181.186pt) -- cycle;
|
||||
\draw[pstyle4] (81.2692pt,181.186pt) -- (235.2932pt,181.186pt);
|
||||
\node at (93.2692pt,161.4799pt)[below right,color=black]{lire("Hello")};
|
||||
\draw[pstyle3] (224.2932pt,208.892pt) -- (234.2932pt,212.892pt) -- (224.2932pt,216.892pt) -- (228.2932pt,212.892pt) -- cycle;
|
||||
\draw[pstyle4] (76.2692pt,212.892pt) -- (230.2932pt,212.892pt);
|
||||
\node at (83.2692pt,193.186pt)[below right,color=black]{saisir(" World")};
|
||||
\draw[pstyle3] (37.45pt,240.598pt) -- (27.45pt,244.598pt) -- (37.45pt,248.598pt) -- (33.45pt,244.598pt) -- cycle;
|
||||
\draw[pstyle4] (31.45pt,244.598pt) -- (235.2932pt,244.598pt);
|
||||
\node at (43.45pt,224.892pt)[below right,color=black]{lire("Hello World")};
|
||||
\draw[pstyle3] (87.2692pt,272.304pt) -- (77.2692pt,276.304pt) -- (87.2692pt,280.304pt) -- (83.2692pt,276.304pt) -- cycle;
|
||||
\draw[pstyle4] (81.2692pt,276.304pt) -- (235.2932pt,276.304pt);
|
||||
\node at (93.2692pt,256.598pt)[below right,color=black]{lire("Hello World")};
|
||||
\end{tikzpicture}
|
||||
@ -0,0 +1,44 @@
|
||||
% generated by Plantuml 1.2022.7
|
||||
\definecolor{plantucolor0000}{RGB}{24,24,24}
|
||||
\definecolor{plantucolor0001}{RGB}{0,0,0}
|
||||
\definecolor{plantucolor0002}{RGB}{226,226,240}
|
||||
\begin{tikzpicture}[yscale=-1
|
||||
,pstyle0/.style={color=plantucolor0000,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
|
||||
,pstyle1/.style={color=plantucolor0000,fill=plantucolor0002,line width=0.5pt}
|
||||
,pstyle2/.style={color=plantucolor0000,line width=0.5pt}
|
||||
,pstyle3/.style={color=plantucolor0000,fill=plantucolor0000,line width=1.0pt}
|
||||
,pstyle4/.style={color=plantucolor0000,line width=1.0pt}
|
||||
]
|
||||
\draw[pstyle0] (26.45pt,84.0679pt) -- (26.45pt,293.892pt);
|
||||
\draw[pstyle0] (230.5952pt,84.0679pt) -- (230.5952pt,293.892pt);
|
||||
\draw[pstyle0] (434.7404pt,84.0679pt) -- (434.7404pt,293.892pt);
|
||||
\node at (5pt,65pt)[below right,color=black]{Alice};
|
||||
\draw[pstyle1] (26.45pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[pstyle2] (26.45pt,21.5pt) -- (26.45pt,48.5pt)(13.45pt,29.5pt) -- (39.45pt,29.5pt)(26.45pt,48.5pt) -- (13.45pt,63.5pt)(26.45pt,48.5pt) -- (39.45pt,63.5pt);
|
||||
\draw[pstyle1] (179.2654pt,55pt) arc (180:270:5pt) -- (184.2654pt,50pt) -- (276.9251pt,50pt) arc (270:360:5pt) -- (281.9251pt,55pt) -- (281.9251pt,78.0679pt) arc (0:90:5pt) -- (276.9251pt,83.0679pt) -- (184.2654pt,83.0679pt) arc (90:180:5pt) -- (179.2654pt,78.0679pt) -- cycle;
|
||||
\node at (186.2654pt,57pt)[below right,color=black]{Application};
|
||||
\node at (416.3712pt,65pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle1] (434.7404pt,13.5pt) ellipse (8pt and 8pt);
|
||||
\draw[pstyle2] (434.7404pt,21.5pt) -- (434.7404pt,48.5pt)(421.7404pt,29.5pt) -- (447.7404pt,29.5pt)(434.7404pt,48.5pt) -- (421.7404pt,63.5pt)(434.7404pt,48.5pt) -- (447.7404pt,63.5pt);
|
||||
\draw[pstyle3] (218.9152pt,126.0519pt) -- (228.5952pt,130.7739pt) -- (218.329pt,134.0304pt) -- (222.6114pt,130.3343pt) -- cycle;
|
||||
\draw[pstyle4] (26.45pt,115.7739pt) -- (228.5952pt,130.7739pt);
|
||||
\node at (33.45pt,96.0679pt)[below right,color=black]{saisir("Le chat")};
|
||||
\draw[pstyle3] (37.13pt,172.7579pt) -- (27.45pt,177.4799pt) -- (37.7162pt,180.7364pt) -- (33.4339pt,177.0403pt) -- cycle;
|
||||
\draw[pstyle4] (229.5952pt,162.4799pt) -- (26.45pt,177.4799pt);
|
||||
\node at (43.45pt,142.7739pt)[below right,color=black]{lire("Le chat")};
|
||||
\draw[pstyle3] (423.0604pt,172.7579pt) -- (432.7404pt,177.4799pt) -- (422.4742pt,180.7364pt) -- (426.7566pt,177.0403pt) -- cycle;
|
||||
\draw[pstyle4] (230.5952pt,162.4799pt) -- (432.7404pt,177.4799pt);
|
||||
\node at (237.5952pt,142.7739pt)[below right,color=black]{lire("Le chat")};
|
||||
\draw[pstyle3] (241.2752pt,219.4639pt) -- (231.5952pt,224.186pt) -- (241.8615pt,227.4424pt) -- (237.5791pt,223.7463pt) -- cycle;
|
||||
\draw[pstyle4] (433.7404pt,209.186pt) -- (230.5952pt,224.186pt);
|
||||
\node at (247.5952pt,189.4799pt)[below right,color=black]{saisir(" mange")};
|
||||
\draw[pstyle3] (219.0329pt,224.23pt) -- (228.5952pt,229.186pt) -- (218.2529pt,232.1919pt) -- (222.6238pt,228.601pt) -- cycle;
|
||||
\draw[pstyle4] (26.45pt,209.186pt) -- (228.5952pt,229.186pt);
|
||||
\node at (33.45pt,189.4799pt)[below right,color=black]{saisir(" boit")};
|
||||
\draw[pstyle3] (37.13pt,271.1699pt) -- (27.45pt,275.892pt) -- (37.7162pt,279.1484pt) -- (33.4339pt,275.4523pt) -- cycle;
|
||||
\draw[pstyle4] (229.5952pt,260.892pt) -- (26.45pt,275.892pt);
|
||||
\node at (43.45pt,241.186pt)[below right,color=black]{lire("Le chat mange boit")};
|
||||
\draw[pstyle3] (423.0604pt,271.1699pt) -- (432.7404pt,275.892pt) -- (422.4742pt,279.1484pt) -- (426.7566pt,275.4523pt) -- cycle;
|
||||
\draw[pstyle4] (230.5952pt,260.892pt) -- (432.7404pt,275.892pt);
|
||||
\node at (237.5952pt,241.186pt)[below right,color=black]{lire("Le chat mange boit")};
|
||||
\end{tikzpicture}
|
||||
@ -0,0 +1,84 @@
|
||||
% generated by Plantuml 1.2022.7
|
||||
\definecolor{plantucolor0000}{RGB}{24,24,24}
|
||||
\definecolor{plantucolor0001}{RGB}{226,226,240}
|
||||
\definecolor{plantucolor0002}{RGB}{0,0,0}
|
||||
\begin{tikzpicture}[yscale=-1
|
||||
,pstyle0/.style={color=plantucolor0000,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
|
||||
,pstyle1/.style={color=plantucolor0000,fill=plantucolor0001,line width=0.5pt}
|
||||
,pstyle2/.style={color=plantucolor0000,line width=1.0pt}
|
||||
,pstyle3/.style={color=plantucolor0000,fill=plantucolor0000,line width=1.0pt}
|
||||
]
|
||||
\draw[pstyle0] (27.3692pt,39.0679pt) -- (27.3692pt,431.4221pt);
|
||||
\draw[pstyle0] (295.551pt,39.0679pt) -- (295.551pt,431.4221pt);
|
||||
\draw[pstyle1] (5pt,10pt) arc (180:270:5pt) -- (10pt,5pt) -- (44.7385pt,5pt) arc (270:360:5pt) -- (49.7385pt,10pt) -- (49.7385pt,33.0679pt) arc (0:90:5pt) -- (44.7385pt,38.0679pt) -- (10pt,38.0679pt) arc (90:180:5pt) -- (5pt,33.0679pt) -- cycle;
|
||||
\node at (12pt,12pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle1] (270.101pt,10pt) arc (180:270:5pt) -- (275.101pt,5pt) -- (316.001pt,5pt) arc (270:360:5pt) -- (321.001pt,10pt) -- (321.001pt,33.0679pt) arc (0:90:5pt) -- (316.001pt,38.0679pt) -- (275.101pt,38.0679pt) arc (90:180:5pt) -- (270.101pt,33.0679pt) -- cycle;
|
||||
\node at (277.101pt,12pt)[below right,color=black]{Alice};
|
||||
\draw[pstyle1] (5pt,436.4221pt) arc (180:270:5pt) -- (10pt,431.4221pt) -- (44.7385pt,431.4221pt) arc (270:360:5pt) -- (49.7385pt,436.4221pt) -- (49.7385pt,459.49pt) arc (0:90:5pt) -- (44.7385pt,464.49pt) -- (10pt,464.49pt) arc (90:180:5pt) -- (5pt,459.49pt) -- cycle;
|
||||
\node at (12pt,438.4221pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle1] (270.101pt,436.4221pt) arc (180:270:5pt) -- (275.101pt,431.4221pt) -- (316.001pt,431.4221pt) arc (270:360:5pt) -- (321.001pt,436.4221pt) -- (321.001pt,459.49pt) arc (0:90:5pt) -- (316.001pt,464.49pt) -- (275.101pt,464.49pt) arc (90:180:5pt) -- (270.101pt,459.49pt) -- cycle;
|
||||
\node at (277.101pt,438.4221pt)[below right,color=black]{Alice};
|
||||
\draw[pstyle2] (27.3692pt,70.7739pt) -- (69.3692pt,70.7739pt);
|
||||
\draw[pstyle2] (69.3692pt,70.7739pt) -- (69.3692pt,83.7739pt);
|
||||
\draw[pstyle2] (28.3692pt,83.7739pt) -- (69.3692pt,83.7739pt);
|
||||
\draw[pstyle3] (38.3692pt,79.7739pt) -- (28.3692pt,83.7739pt) -- (38.3692pt,87.7739pt) -- (34.3692pt,83.7739pt) -- cycle;
|
||||
\node at (34.3692pt,51.0679pt)[below right,color=black]{inserer("Hello World")};
|
||||
\draw[pstyle2] (27.3692pt,115.4799pt) -- (69.3692pt,115.4799pt);
|
||||
\draw[pstyle2] (69.3692pt,115.4799pt) -- (69.3692pt,128.4799pt);
|
||||
\draw[pstyle2] (28.3692pt,128.4799pt) -- (69.3692pt,128.4799pt);
|
||||
\draw[pstyle3] (38.3692pt,124.4799pt) -- (28.3692pt,128.4799pt) -- (38.3692pt,132.4799pt) -- (34.3692pt,128.4799pt) -- cycle;
|
||||
\node at (34.3692pt,95.7739pt)[below right,color=black]{afficher() -\textgreater "Hello World"};
|
||||
\draw[pstyle3] (283.551pt,156.186pt) -- (293.551pt,160.186pt) -- (283.551pt,164.186pt) -- (287.551pt,160.186pt) -- cycle;
|
||||
\draw[pstyle2] (27.3692pt,160.186pt) -- (289.551pt,160.186pt);
|
||||
\node at (34.3692pt,140.4799pt)[below right,color=black]{partager("Hello World")};
|
||||
\draw[pstyle2] (295.551pt,191.892pt) -- (337.551pt,191.892pt);
|
||||
\draw[pstyle2] (337.551pt,191.892pt) -- (337.551pt,204.892pt);
|
||||
\draw[pstyle2] (296.551pt,204.892pt) -- (337.551pt,204.892pt);
|
||||
\draw[pstyle3] (306.551pt,200.892pt) -- (296.551pt,204.892pt) -- (306.551pt,208.892pt) -- (302.551pt,204.892pt) -- cycle;
|
||||
\node at (302.551pt,172.186pt)[below right,color=black]{afficher() : "Hello World"};
|
||||
\draw[pstyle2] (295.551pt,236.598pt) -- (337.551pt,236.598pt);
|
||||
\draw[pstyle2] (337.551pt,236.598pt) -- (337.551pt,249.598pt);
|
||||
\draw[pstyle2] (296.551pt,249.598pt) -- (337.551pt,249.598pt);
|
||||
\draw[pstyle3] (306.551pt,245.598pt) -- (296.551pt,249.598pt) -- (306.551pt,253.598pt) -- (302.551pt,249.598pt) -- cycle;
|
||||
\node at (302.551pt,216.892pt)[below right,color=black]{souligner("Hello World")};
|
||||
\draw[pstyle2] (27.3692pt,236.598pt) -- (69.3692pt,236.598pt);
|
||||
\draw[pstyle2] (69.3692pt,236.598pt) -- (69.3692pt,249.598pt);
|
||||
\draw[pstyle2] (28.3692pt,249.598pt) -- (69.3692pt,249.598pt);
|
||||
\draw[pstyle3] (38.3692pt,245.598pt) -- (28.3692pt,249.598pt) -- (38.3692pt,253.598pt) -- (34.3692pt,249.598pt) -- cycle;
|
||||
\node at (34.3692pt,216.892pt)[below right,color=black]{supprimer("Hello World", " World")};
|
||||
\draw[pstyle2] (295.551pt,281.304pt) -- (337.551pt,281.304pt);
|
||||
\draw[pstyle2] (337.551pt,281.304pt) -- (337.551pt,294.304pt);
|
||||
\draw[pstyle2] (296.551pt,294.304pt) -- (337.551pt,294.304pt);
|
||||
\draw[pstyle3] (306.551pt,290.304pt) -- (296.551pt,294.304pt) -- (306.551pt,298.304pt) -- (302.551pt,294.304pt) -- cycle;
|
||||
\node at (302.551pt,261.598pt)[below right,color=black]{afficher() : "};
|
||||
\node at (385.8771pt,261.598pt)[below right,color=black]{\underline{Hello World}};
|
||||
\node at (474.4455pt,261.598pt)[below right,color=black]{"};
|
||||
\draw[pstyle2] (27.3692pt,281.304pt) -- (69.3692pt,281.304pt);
|
||||
\draw[pstyle2] (69.3692pt,281.304pt) -- (69.3692pt,294.304pt);
|
||||
\draw[pstyle2] (28.3692pt,294.304pt) -- (69.3692pt,294.304pt);
|
||||
\draw[pstyle3] (38.3692pt,290.304pt) -- (28.3692pt,294.304pt) -- (38.3692pt,298.304pt) -- (34.3692pt,294.304pt) -- cycle;
|
||||
\node at (34.3692pt,261.598pt)[below right,color=black]{afficher() : "Hello"};
|
||||
\draw[pstyle3] (37.9548pt,363.8051pt) -- (28.3692pt,368.716pt) -- (38.6973pt,371.7706pt) -- (34.3433pt,368.1591pt) -- cycle;
|
||||
\draw[pstyle2] (294.551pt,343.716pt) -- (27.3692pt,368.716pt);
|
||||
\node at (44.3692pt,306.304pt)[below right,color=black]{\t \t partager("};
|
||||
\node at (177.2298pt,306.304pt)[below right,color=black]{\underline{Hello World}};
|
||||
\node at (265.7983pt,306.304pt)[below right,color=black]{")};
|
||||
\node at (44.3692pt,324.01pt)[below right,color=black]{ };
|
||||
\draw[pstyle3] (283.9655pt,363.8051pt) -- (293.551pt,368.716pt) -- (283.2229pt,371.7706pt) -- (287.577pt,368.1591pt) -- cycle;
|
||||
\draw[pstyle2] (27.3692pt,343.716pt) -- (293.551pt,368.716pt);
|
||||
\node at (34.3692pt,324.01pt)[below right,color=black]{partager("Hello")};
|
||||
\draw[pstyle2] (27.3692pt,400.4221pt) -- (69.3692pt,400.4221pt);
|
||||
\draw[pstyle2] (69.3692pt,400.4221pt) -- (69.3692pt,413.4221pt);
|
||||
\draw[pstyle2] (28.3692pt,413.4221pt) -- (69.3692pt,413.4221pt);
|
||||
\draw[pstyle3] (38.3692pt,409.4221pt) -- (28.3692pt,413.4221pt) -- (38.3692pt,417.4221pt) -- (34.3692pt,413.4221pt) -- cycle;
|
||||
\node at (34.3692pt,380.716pt)[below right,color=black]{afficher() -\textgreater "};
|
||||
\node at (127.1192pt,380.716pt)[below right,color=black]{\underline{Hello World}};
|
||||
\node at (215.6877pt,380.716pt)[below right,color=black]{"};
|
||||
\draw[pstyle2] (295.551pt,400.4221pt) -- (337.551pt,400.4221pt);
|
||||
\draw[pstyle2] (337.551pt,400.4221pt) -- (337.551pt,413.4221pt);
|
||||
\draw[pstyle2] (296.551pt,413.4221pt) -- (337.551pt,413.4221pt);
|
||||
\draw[pstyle3] (306.551pt,409.4221pt) -- (296.551pt,413.4221pt) -- (306.551pt,417.4221pt) -- (302.551pt,413.4221pt) -- cycle;
|
||||
\node at (302.551pt,380.716pt)[below right,color=black]{afficher() -\textgreater "};
|
||||
\node at (395.301pt,380.716pt)[below right,color=black]{\underline{Hello}};
|
||||
\node at (434.1738pt,380.716pt)[below right,color=black]{"};
|
||||
\end{tikzpicture}
|
||||
@ -0,0 +1,57 @@
|
||||
% generated by Plantuml 1.2022.7
|
||||
\definecolor{plantucolor0000}{RGB}{24,24,24}
|
||||
\definecolor{plantucolor0001}{RGB}{226,226,240}
|
||||
\definecolor{plantucolor0002}{RGB}{0,0,0}
|
||||
\begin{tikzpicture}[yscale=-1
|
||||
,pstyle0/.style={color=plantucolor0000,line width=0.5pt,dash pattern=on 5.0pt off 5.0pt}
|
||||
,pstyle1/.style={color=plantucolor0000,fill=plantucolor0001,line width=0.5pt}
|
||||
,pstyle2/.style={color=plantucolor0000,fill=plantucolor0000,line width=1.0pt}
|
||||
,pstyle3/.style={color=plantucolor0000,line width=1.0pt}
|
||||
,pstyle4/.style={color=plantucolor0000,line width=1.0pt,dash pattern=on 2.0pt off 2.0pt}
|
||||
]
|
||||
\draw[pstyle0] (30.45pt,39.0679pt) -- (30.45pt,434.1281pt);
|
||||
\draw[pstyle0] (210.5241pt,39.0679pt) -- (210.5241pt,434.1281pt);
|
||||
\draw[pstyle0] (328.7611pt,39.0679pt) -- (328.7611pt,434.1281pt);
|
||||
\draw[pstyle1] (5pt,10pt) arc (180:270:5pt) -- (10pt,5pt) -- (50.9pt,5pt) arc (270:360:5pt) -- (55.9pt,10pt) -- (55.9pt,33.0679pt) arc (0:90:5pt) -- (50.9pt,38.0679pt) -- (10pt,38.0679pt) arc (90:180:5pt) -- (5pt,33.0679pt) -- cycle;
|
||||
\node at (12pt,12pt)[below right,color=black]{Alice};
|
||||
\draw[pstyle1] (177.9423pt,10pt) arc (180:270:5pt) -- (182.9423pt,5pt) -- (238.1059pt,5pt) arc (270:360:5pt) -- (243.1059pt,10pt) -- (243.1059pt,33.0679pt) arc (0:90:5pt) -- (238.1059pt,38.0679pt) -- (182.9423pt,38.0679pt) arc (90:180:5pt) -- (177.9423pt,33.0679pt) -- cycle;
|
||||
\node at (184.9423pt,12pt)[below right,color=black]{Server};
|
||||
\draw[pstyle1] (306.3919pt,10pt) arc (180:270:5pt) -- (311.3919pt,5pt) -- (346.1303pt,5pt) arc (270:360:5pt) -- (351.1303pt,10pt) -- (351.1303pt,33.0679pt) arc (0:90:5pt) -- (346.1303pt,38.0679pt) -- (311.3919pt,38.0679pt) arc (90:180:5pt) -- (306.3919pt,33.0679pt) -- cycle;
|
||||
\node at (313.3919pt,12pt)[below right,color=black]{Bob};
|
||||
\draw[pstyle2] (198.7612pt,76.2256pt) -- (208.5241pt,80.7739pt) -- (198.3177pt,84.2133pt) -- (202.5333pt,80.4412pt) -- cycle;
|
||||
\draw[pstyle3] (30.45pt,70.7739pt) -- (208.5241pt,80.7739pt);
|
||||
\node at (37.45pt,51.0679pt)[below right,color=black]{lock()};
|
||||
\draw[pstyle2] (41.2128pt,117.9316pt) -- (31.45pt,122.4799pt) -- (41.6564pt,125.9193pt) -- (37.4408pt,122.1473pt) -- cycle;
|
||||
\draw[pstyle4] (209.5241pt,112.4799pt) -- (30.45pt,122.4799pt);
|
||||
\node at (47.45pt,92.7739pt)[below right,color=black]{true};
|
||||
\draw[pstyle2] (221.5241pt,150.186pt) -- (211.5241pt,154.186pt) -- (221.5241pt,158.186pt) -- (217.5241pt,154.186pt) -- cycle;
|
||||
\draw[pstyle3] (215.5241pt,154.186pt) -- (327.7611pt,154.186pt);
|
||||
\node at (227.5241pt,134.4799pt)[below right,color=black]{lock()};
|
||||
\draw[pstyle2] (198.7612pt,159.6376pt) -- (208.5241pt,164.186pt) -- (198.3177pt,167.6253pt) -- (202.5333pt,163.8533pt) -- cycle;
|
||||
\draw[pstyle3] (30.45pt,154.186pt) -- (208.5241pt,164.186pt);
|
||||
\node at (37.45pt,134.4799pt)[below right,color=black]{inserer("hello world")};
|
||||
\draw[pstyle2] (317.1338pt,201.0635pt) -- (326.7611pt,205.892pt) -- (316.4596pt,209.035pt) -- (320.7825pt,205.3863pt) -- cycle;
|
||||
\draw[pstyle4] (210.5241pt,195.892pt) -- (326.7611pt,205.892pt);
|
||||
\node at (217.5241pt,176.186pt)[below right,color=black]{false};
|
||||
\draw[pstyle2] (198.7612pt,201.3437pt) -- (208.5241pt,205.892pt) -- (198.3177pt,209.3314pt) -- (202.5333pt,205.5593pt) -- cycle;
|
||||
\draw[pstyle3] (30.45pt,195.892pt) -- (208.5241pt,205.892pt);
|
||||
\node at (37.45pt,176.186pt)[below right,color=black]{lire()};
|
||||
\draw[pstyle2] (41.2128pt,243.0497pt) -- (31.45pt,247.598pt) -- (41.6564pt,251.0374pt) -- (37.4408pt,247.2653pt) -- cycle;
|
||||
\draw[pstyle4] (209.5241pt,237.598pt) -- (30.45pt,247.598pt);
|
||||
\node at (47.45pt,217.892pt)[below right,color=black]{"hello world"};
|
||||
\draw[pstyle2] (198.5241pt,275.304pt) -- (208.5241pt,279.304pt) -- (198.5241pt,283.304pt) -- (202.5241pt,279.304pt) -- cycle;
|
||||
\draw[pstyle3] (30.45pt,279.304pt) -- (204.5241pt,279.304pt);
|
||||
\node at (37.45pt,259.598pt)[below right,color=black]{unlock()};
|
||||
\draw[pstyle2] (221.5241pt,307.01pt) -- (211.5241pt,311.01pt) -- (221.5241pt,315.01pt) -- (217.5241pt,311.01pt) -- cycle;
|
||||
\draw[pstyle3] (215.5241pt,311.01pt) -- (327.7611pt,311.01pt);
|
||||
\node at (227.5241pt,291.304pt)[below right,color=black]{lock()};
|
||||
\draw[pstyle2] (221.5241pt,338.716pt) -- (211.5241pt,342.716pt) -- (221.5241pt,346.716pt) -- (217.5241pt,342.716pt) -- cycle;
|
||||
\draw[pstyle3] (215.5241pt,342.716pt) -- (327.7611pt,342.716pt);
|
||||
\node at (227.5241pt,323.01pt)[below right,color=black]{lire()};
|
||||
\draw[pstyle2] (317.1338pt,379.5935pt) -- (326.7611pt,384.4221pt) -- (316.4596pt,387.5651pt) -- (320.7825pt,383.9164pt) -- cycle;
|
||||
\draw[pstyle4] (210.5241pt,374.4221pt) -- (326.7611pt,384.4221pt);
|
||||
\node at (217.5241pt,354.716pt)[below right,color=black]{"hello world"};
|
||||
\draw[pstyle2] (221.5241pt,412.1281pt) -- (211.5241pt,416.1281pt) -- (221.5241pt,420.1281pt) -- (217.5241pt,416.1281pt) -- cycle;
|
||||
\draw[pstyle3] (215.5241pt,416.1281pt) -- (327.7611pt,416.1281pt);
|
||||
\node at (227.5241pt,396.4221pt)[below right,color=black]{unlock()};
|
||||
\end{tikzpicture}
|
||||
Loading…
Reference in New Issue
Block a user