|
|
@@ -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.
|
