|
@@ -17,11 +17,28 @@ Dans ce modèle, on considère un processus privilégié qu'on appelle broker, q
|
|
|
va contrôler tous les échanges entre les différents processus qu'on appelle
|
|
va contrôler tous les échanges entre les différents processus qu'on appelle
|
|
|
workers, mais également leur cycle de vie et leurs permissions et accès.
|
|
workers, mais également leur cycle de vie et leurs permissions et accès.
|
|
|
|
|
|
|
|
|
|
+%TODO: schéma broker-worker
|
|
|
|
|
+
|
|
|
Le broker est donc en charge de faire le routage des différents messages, de
|
|
Le broker est donc en charge de faire le routage des différents messages, de
|
|
|
transmettre les ressources et faire la vérification d'accès. Il est également
|
|
transmettre les ressources et faire la vérification d'accès. Il est également
|
|
|
utile pour vérifier que les processus workers sont encore en vie et signaler les
|
|
utile pour vérifier que les processus workers sont encore en vie et signaler les
|
|
|
erreurs.
|
|
erreurs.
|
|
|
|
|
|
|
|
|
|
+Les avantages du modèle broker sont qu'il est généralement le modèle le plus
|
|
|
|
|
+simple à implémenter, et n'a pas besoin de fonctionnalité particulière du point
|
|
|
|
|
+de vue du système, à part pour créer les IPC. Il est également bien plus simple
|
|
|
|
|
+à comprendre, à développer, à isoler et à suivre étant donné que tous les
|
|
|
|
|
+échanges passent par le broker avant d'être transmis au bon processus. Ce
|
|
|
|
|
+modèle constitue ainsi un cadre privilégié pour développer la sandbox et
|
|
|
|
|
+l'amener sur tous les système, à condition de garder en tête les contraintes
|
|
|
|
|
+des autres modèles.
|
|
|
|
|
+
|
|
|
|
|
+Le processus broker sera initialisé dans le processus principal et sera donc
|
|
|
|
|
+père de tous les autres processus de la sandbox. Cela permettra d'utiliser des
|
|
|
|
|
+techniques comme \texttt{ptrace} sous Linux ou d'avoir les droits sur les objets
|
|
|
|
|
+des autres processus sous Windows sans avoir à recourir à des droits de
|
|
|
|
|
+superutilisateur.
|
|
|
|
|
+
|
|
|
\section{Le modèle orchestrateur}
|
|
\section{Le modèle orchestrateur}
|
|
|
|
|
|
|
|
Dans ce modèle, on considère un processus privilégié qu'on appelle
|
|
Dans ce modèle, on considère un processus privilégié qu'on appelle
|
|
@@ -33,6 +50,12 @@ donné qu'on diminue les changements de contexte et appels systèmes. On garde c
|
|
|
fonctionner de façon indépendante après, du moment que tous les éléments qui
|
|
fonctionner de façon indépendante après, du moment que tous les éléments qui
|
|
|
sont liés à l'étage ont été créés.
|
|
sont liés à l'étage ont été créés.
|
|
|
|
|
|
|
|
|
|
+%TODO: schéma orchestrateur-worker
|
|
|
|
|
+
|
|
|
|
|
+\section{Les processus worker}
|
|
|
|
|
+
|
|
|
|
|
+%TODO: décrire rôle du processus worker
|
|
|
|
|
+
|
|
|
\section{La notion de processus Zygote}
|
|
\section{La notion de processus Zygote}
|
|
|
|
|
|
|
|
Afin d'optimiser le démarrage de nouveaux processus, beaucoup de systèmes
|
|
Afin d'optimiser le démarrage de nouveaux processus, beaucoup de systèmes
|
