chapters/windows_ipc: améliore la mise en forme et les détails sur le transfert

chapters/windows_ipc.tex

@@ -9,29 +9,39 @@ similaire.
 \section{Communication inter-processus}
 
 Windows dispose de beaucoup de moyen de communication inter-processus. Parmi
-ceux là, aucun ne va avoir les mêmes propriétés que les sockets Unix. On peut
-citer:
-
-\begin{itemize}
-    \item Les Windows sockets, qui réimplémentent la même interface que les
-    sockets Berkeley mais ne fournissent pas de sockets locaux ou anonymes.
-    Ceux-ci passent par la pile réseau pour l'envoi de message. On notera
-    cependant l'implémentation de «TCP Loopback Fast Path» depuis Windows Server
-    2012. Cette fonctionnalité conserve la sémantique du protocole TCP tout en
-    désactivant des fonctionnalités comme l'algorithme de Nagle. C'est donc ce
-    qui ressemble le plus aux sockets Unix, excepté l'accès au réseau et le
-    passage de descripteur de fichiers.
-    https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
-
-    \item Les canaux anonymes, qui donnent un moyen de communication
-    unidirectionnel avec un écrivain et un lecteur. Il faut donc utiliser une
-    paire de pipe anonyme pour pouvoir discuter en full-duplex.
-
-    \item Les canaux nommés, qui sont capables de fonctionner en duplex
-\end{itemize}
-
-Ici, on va d'abord s'intéresser aux canaux nommés et voir comment on peut les
-utiliser pour transmettre des messages et des ressources.
+ceux là, aucun ne va avoir les mêmes propriétés que les sockets Unix. 
+
+\subsection{Les sockets Windows}
+
+Les sockets Windows réimplémentent la même interface que les sockets Berkeley
+mais ne fournissent pas de sockets locaux ou anonymes.  Ceux-ci passent par la
+pile réseau pour l'envoi de message. On notera cependant l'implémentation de
+«TCP Loopback Fast Path» depuis Windows Server 2012. Cette fonctionnalité
+conserve la sémantique du protocole TCP tout en désactivant des fonctionnalités
+comme l'algorithme de Nagle. C'est donc ce qui ressemble le plus aux sockets
+Unix, excepté l'accès au réseau et le passage de descripteur de fichiers.
+https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
+
+\subsection{Les canaux anonymes}
+
+Les canaux anonymes donnent un moyen de communication unidirectionnel avec un
+écrivain et un lecteur. Il faut donc utiliser une paire de canaux anonyme pour
+pouvoir discuter en full-duplex, mais également utiliser un mécanisme pour
+transmettre le \inltype{HANDLE} d'un processus à l'autre. À noter que la plupart
+des fonctions sur les canaux nommés fonctionnent avec les canaux anonymes, ces
+derniers étant implémentés comme des canaux nommés avec un nom particulier.
+
+\subsection{Les canaux nommés}
+
+Les canaux nommés sont capables de fonctionner en full-duplex et disposent
+pleinement du système d'ACL global de Windows.
+
+Ici, on va plutôt s'intéresser aux canaux nommés et voir comment on peut les
+utiliser pour transmettre des messages et des ressources. La création d'un canal
+nommé se fait avec avec la famille de fonction \inltype{CreateNamedPipe}. Dans
+notre cas, on sera fortement tenté d'utiliser des \inltype{lpSecurityAttributes}
+définis avec de bonnes valeurs, mais ce point sera exploré dans la suite du
+document.
 
 \begin{code}{c}{Prototype de \inltype{CreateNamedPipe}}
 HANDLE CreateNamedPipeA(
@@ -46,6 +56,8 @@ HANDLE CreateNamedPipeA(
 );
 \end{code}
 
+\section{Transfert de ressource entre processus}
+
 Windows disposent de trois mécanismes pour partager des ressources entre
 processus. Les ressources sont représentées par des objets \inltype{HANDLE}.
 
@@ -76,10 +88,31 @@ BOOL WINAPI DuplicateHandle(
 );
 \end{code}
 
+L'exploitation de \inltype{DuplicateHandle} demande à ce que chacun des deux
+processus rentrant en jeu dans la fonction, à savoir
+\inltype{hSourceProcessHandle} et \inltype{hTargetProcessHandle} disposent du
+droit \inltype{PROCESS_DUP_HANDLE}. Étant donné que la fonction peut être
+utilisée de la source vers la destination ou depuis la destination récupérant un
+\inltype{HANDLE} appartenant à la source, le processus ayant accès à l'autre
+processus est capable de copier tout accès existant et dispose donc des mêmes
+droits que l'autre processus.
+
+Cette remarque est importante pour se rendre compte que l'utilisation de cette
+méthode implique nécessairement un broker, qui sera suffisamment privilégié pour
+accéder aux deux processus souhaitant partager une ressource. Tenter d'appliquer
+cette fonction directement dans les workers impliquerait que chacun des workers
+auraient les mêmes droits que ses voisin et, de façon transitive, aurait accès à
+toutes les zones de privilèges connexes dans le graphe d'IPC.
+
 Enfin, la troisième méthode consiste à utiliser les objets nommées qui sont
 créés d'un côté par le processus parent, puis ouvert par les processus enfants
 en les référençant par leur nom.
 
 Dans le prototype, j'ai utilisé des canaux nommés pour faciliter la mise en place
 mais j'ai également essayé d'utiliser des paires de canaux anonymes dans d'autres
-codes isolés.
+codes simulant le fonctionnement des IPC. J'ai également prévu de mettre en
+place la méthode utilisant \inltype{DuplicateHandle} et donc un broker central
+pour pouvoir transférer des ressources de la même façon que sous Linux.
+J'essayerai cependant de m'approcher d'un modèle orchestrateur avec d'autres
+techniques mais nous allons voir qu'il n'y a pas vraiment d'alternative pour
+l'instant.