internship-report-vlc/chapters/windows_ipc.tex

% TODO: remplacer confiant
Après les présentations des objectifs liés aux communications inter-processus et
de l'implémentation Linux, nous pouvons être assez confiant sur l'implémentation
Windows. Malheureusement celle-ci vient nous rappeler qu'un changement de
système implique parfois un changement de paradigme. La documentation quelque
peu hasardeuse va néanmoins nous permettre de mettre en place une architecture
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.

\begin{code}{c}{Prototype de \inltype{CreateNamedPipe}}
HANDLE CreateNamedPipeA(
  LPCSTR                lpName,
  DWORD                 dwOpenMode,
  DWORD                 dwPipeMode,
  DWORD                 nMaxInstances,
  DWORD                 nOutBufferSize,
  DWORD                 nInBufferSize,
  DWORD                 nDefaultTimeOut,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes
);
\end{code}

Windows disposent de trois mécanismes pour partager des ressources entre
processus. Les ressources sont représentées par des objets \inltype{HANDLE}.

La première méthode est l'héritage, qui a lieu lors de la création d'un nouveau
processus. Les descripteurs de fichiers marqués comme héritable, ou bien aucun
si \inltype{bInheritHandles} est précisé à \inltype{FALSE} lors de l'appel de
\inltype{CreateProcess}, seront récupérés dans le nouveau processus avec la même
valeur. Lorsqu'un \inltype{HANDLE} est hérité, il garde la même valeur dans le
nouveau processus et il faut donc le transmettre soit par IPC, soit par
paramètre de la ligne de commande, soit par injection de code dans le nouveau
processus.

La seconde méthode utilise la fonction \inltype{DuplicateHandle} pour injecter
le descripteur de fichier dans le nouveau processus. Dans ce cas-là, si l'appel
est fait depuis le processus parent, une nouvelle valeur est générée pour ce
\inltype{HANDLE} et il faut le transmettre au processus enfant par l'une des
méthodes mentionnées dans le cas de l'héritage.

\begin{code}{c}{Prototype de la fonction \inltype{DuplicateHandle}}
BOOL WINAPI DuplicateHandle(
  _In_  HANDLE   hSourceProcessHandle,
  _In_  HANDLE   hSourceHandle,
  _In_  HANDLE   hTargetProcessHandle,
  _Out_ LPHANDLE lpTargetHandle,
  _In_  DWORD    dwDesiredAccess,
  _In_  BOOL     bInheritHandle,
  _In_  DWORD    dwOptions
);
\end{code}

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.