chapters/sandbox_ipc: fusion lien dans ipc

chapters/sandbox_ipc.tex

@@ -16,11 +16,31 @@ Bien entendu, reproduire l'architecture de VLC implique que les RPCs puissent
 renvoyer des valeurs et il faut donc que la communication entre deux étages soit
 systématiquement bidirectionnelle si elle existe.
 
+\section{Simplification vers le modèle broker}
+
 La situation n'est pas totalement la même entre une architecture broker et une
-architecture orchestrateur, mais nous verrons dans la suite qu'on peut se
-ramener de la seconde à la première sans trop de soucis d'abstraction. On peut
-donc raisonner sur un mode de fonctionnement avec broker, puis essayer de voir
-si l'étendre peut poser problème.
+architecture orchestrateur, mais nous allons voir que l'on peut se ramener de la
+seconde à la première sans perte d'abstraction dès lors qu'on peut produire des
+jetons d'accès pour les IPC.
+
+On peut en effet réaliser la construction suivante. On représente chaque lien
+entre deux processus par une paire d'objets \inltype{vlc_process_ipc_t}
+distribuée entre les deux processus. Il s'agit alors du modèle orchestrateur.
+
+Maintenant on le modifie pour casser le lien en deux et passer avec une
+architecture broker. Chaque lien devient donc une paire de lien avec d’abord une
+connexion worker-broker puis une autre connexion broker-worker. Le broker
+s’assure ainsi de faire le routage et vérifier les accès.
+
+On a donc découplé le fonctionnement du worker de la politique d’accès choisie.
+Cette propriété est très importante pour la suite, car elle permet de construire
+le modèle puis d’adapter l’implémentation à ce qui se rapproche le plus du
+fonctionnement du système sous-jacent.
+
+En pratique, ce comportement est actuellement obtenu avec de simples indices,
+n'apportant pas la garantie de sécurité attendue pour une sandbox mais
+permettant de tester et déboguer plus facilement le comportement de
+l'application en multiprocessus.
 
 \section{Abstraction des messages et RPC}
 
@@ -30,10 +50,29 @@ si l'étendre peut poser problème.
 % TODO: implémentation broker
 
 On a également besoin d'un moyen de sérialiser et envoyer des messages pour
-construire les appels de fonctions déportés (RPC, pour Remote Procedure Call).
+construire les appels de fonctions déportés (RPC, pour Remote Procedure Call)
+qui vont nous permettre de conserver le même modèle d'exécution qu'en
+multithread.
+
+N'étant pas le sujet principal et étant un problème déjà résolu de beaucoup de
+façon différentes, mon implémentation de ces messages est réduite à l'essentiel
+et permet d'une part de créer des messages avec \inltype{vlc_process_msg_new},
+puis d'autre part de sérialiser ou désérialiser des données dedans à partir de
+fonctions du type \inltype{vlc_msg_recv_{type}} ou
+\inltype{vlc_msg_append_{type}}.
+
+Étant donnée que l'architecture précédente est simulée avec des indices,
+les messages doivent indiquer le processus de destination. Ils doivent également
+indiquer l'action à effectuer, correspondant à une table indice vers type de RPC
+appelable.
 
 \section{Abstraction des moyens de communication}
 
-On introduit donc le type \inltype{vlc_process_ipc_t} qui est capable de
-stocker ce bus de communication bidirectionnel et on construit les fonctions
-de communication dessus.
+Pour masquer les détails de l'implémentation du bus de communication entre les
+processus, on introduit le type \inltype{vlc_process_ipc_t} qui est capable de
+stocker ce bus bidirectionnel et on construit les fonctions de communication
+dessus.
+
+En particulier, on va retrouver deux fonctions principales. Tout d'abord,
+\inltype{vlc_ipc_SendMsg} permet à partir d'envoyer un message et ses
+descripteurs de fichier sur une IPC.

main.tex

@@ -89,9 +89,6 @@ Renforcement de la sécurité d'un lecteur vidéo multiplate-forme par séparati
 \chapter{Communication inter-processus}
 \input{chapters/sandbox_ipc}
 
-\chapter{Initialisation des liens entre modules}
-\input{chapters/sandbox_init_links}
-
 \chapter{Gestion des messages reçus: boucle événementielle}
 \input{chapters/sandbox_eventloop}
 
@@ -111,9 +108,9 @@ Renforcement de la sécurité d'un lecteur vidéo multiplate-forme par séparati
 \chapter{Gestion asynchrone des messages reçus}
 \input{chapters/linux_eventloop}
 
-\chapter{Routage des messages dans les différents modèles}
-
-\chapter{Gestion des accès et permissions via socket unix et descripteur de fichiers}
+% \chapter{Routage des messages dans les différents modèles}
+%
+% \chapter{Gestion des accès et permissions via socket unix et descripteur de fichiers}
 
 
 \part{Implémentation de la sandbox sous Windows}
@@ -123,9 +120,9 @@ Renforcement de la sécurité d'un lecteur vidéo multiplate-forme par séparati
 \chapter{Gestion asynchrone des messages reçus}
 \input{chapters/windows_eventloop}
 
-\chapter{Routage des messages dans le modèle broker}
-
-\chapter{Gestion des accès et de la mémoire via ACL}
+%\chapter{Routage des messages dans le modèle broker}
+%
+%\chapter{Gestion des accès et de la mémoire via ACL}
 
 
 \part{Finalisation et optimisation d'un moteur de rendu pour la réalité virtuelle}