|
|
@@ -32,15 +32,18 @@ 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
|
|
|
erreurs.
|
|
|
|
|
|
-% TODO: expliauer IPC
|
|
|
+% TODO: expliquer IPC
|
|
|
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èmes, à condition de garder en tête les contraintes
|
|
|
-des autres modèles.
|
|
|
+de vue du système, à part pour créer les communications inter-processus (IPC).
|
|
|
+Nous pouvons même simuler toutes les problématiques d'accès par des jetons
|
|
|
+d'accès représenté par une certaine IPC, que le broker associera à un accès réel
|
|
|
+et reproduira les actions demandées par le worker. 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èmes, à 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
|
|
|
@@ -59,11 +62,36 @@ donné qu'on diminue les changements de contexte et appels systèmes. On garde c
|
|
|
fonctionner indépendamment après, du moment que tous les éléments qui
|
|
|
sont liés à l'étage ont été créés.
|
|
|
|
|
|
+Ce modèle nécessite la possibilité d'initialiser une IPC entre deux workers qui
|
|
|
+doivent communiquer, mais potentiellement aussi mettre en place une autre IPC
|
|
|
+plus efficace pour les transferts de données du pipeline, commme des mémoire
|
|
|
+partagées. Il faut également que dans ce modèle, les workers ne puissent pas
|
|
|
+récupérer les droits des autres workers.
|
|
|
+
|
|
|
+C'est grâce à ce modèle qu'on peut mettre en valeur la puissance d'expression et
|
|
|
+de contrôle des jetons d'accès, car aucun contrôle de l'orchestrateur n'est
|
|
|
+nécessaire pour appliquer une réduction des privilèges et définir précisément
|
|
|
+les accès disponibles dans chaque partie du pipeline par conception plutôt que
|
|
|
+par des règles et contrôles d'accès.
|
|
|
+
|
|
|
%TODO: schéma orchestrateur-worker
|
|
|
|
|
|
\section{Les processus worker}
|
|
|
|
|
|
%TODO: décrire rôle du processus worker
|
|
|
+Dans les deux modèles précédents, on a utilisé des processus workers qui vont
|
|
|
+avoir le même rôle, mais éventuellement des implémentations différentes.
|
|
|
+
|
|
|
+Chaque worker est équipé d'un thread jouant le rôle de boucle événementielle et
|
|
|
+récupérant les messages soit de tous les autres modules connectés, soit depuis
|
|
|
+le broker uniquement selon le modèle utilisé. La boucle événementielle sera
|
|
|
+décrite plus tard.
|
|
|
+
|
|
|
+Les workers peuvent démarrer de plusieurs façons. Soit un nouveau processus est
|
|
|
+créé en étant configuré comme un worker, avec des IPC correctes déjà attribuées.
|
|
|
+Soit le processus est créé depuis un fork et le thread worker peut démarrer tout
|
|
|
+de suite en ayant connaissance de son IPC vers l'orchestrateur ou le broker. La
|
|
|
+seconde option peut notamment apparaître lorsqu'un processus Zygote est utilisé.
|
|
|
|
|
|
\section{La notion de processus Zygote}
|
|
|
|
|
|
@@ -88,7 +116,7 @@ systématique de libération de tous les descripteurs associés au processus si
|
|
|
l'on ne souhaite pas utiliser ce processus pour des raisons de performances
|
|
|
également.
|
|
|
|
|
|
-Néanmoins, la partie la plus intéressante du Zygote concerne le débogage de la
|
|
|
+Néanmoins, l'autre partie très intéressante du Zygote concerne le débogage de la
|
|
|
sandbox. Sous Linux, \texttt{gdb} n'est capable de s'accrocher qu'à un seul
|
|
|
processus à la fois. Il faut alors choisir avec \texttt{set follow-fork-mode} si
|
|
|
l'on veut déboguer le processus parent ou bien le processus enfant lors d'un
|
