internship-report-vlc/chapters/sandbox_ipc.tex

\section{Motivation}

Chacun des morceaux de l'architecture de VLC se retrouvant isolé dans des
processus indépendant, on a besoin d'un moyen de créer une communication
inter-processus. Plus encore, on a besoin de pouvoir transférer la capacité de
communiquer d'un processus à l'autre de façon à contrôler de façon fiable les
autorisations de chaque processus.

La communication entre les processus est importante car il s'agit de la base
pour pouvoir effectuer des appels de fonctions distants -- ou RPC pour Remote
Procedure Call.  Cela va notamment nous servir à reproduire le modèle
d'exécution actuel de VLC pour le faire progressivement évoluer vers une
architecture plus découplée et moins contrainte.

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 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}

% TODO: framework de sérialisation
% TODO: format du message envoyés (header)
% TODO: framework d'envoi et de réception
% 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)
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}

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, puis \inltype{vlc_ipc_RecvMsg} qui
allouera le message et récupèrera les descripteurs de fichiers.

\begin{code}{c}{Prototypes des fonctions d'envoi de messages}
VLC_API int
vlc_ipc_SendMsg( vlc_process_ipc_t *p_ipc, vlc_process_msg_t *p_msg );

VLC_API int
vlc_ipc_RecvMsg( vlc_process_ipc_t *p_ipc, vlc_process_msg_t **pp_msg );
\end{code}