À propos de la distribution d’homologues
L’API de distribution d’homologues, qui prend en charge la fonctionnalité Cache de branche dans Windows 7, Windows Server 2008 R2, Windows 8 et Windows Server 2012 offre un ensemble d’API de plateforme qui peuvent augmenter la réactivité du réseau des applications centralisées lorsqu’elles sont accessibles à partir de bureaux distants et aider à réduire l’utilisation globale du réseau étendu (WAN) sans interférer avec les technologies de sécurité réseau.
Le système peer distribution propose un ensemble d’API de plateforme utilisées à la fois par les éditeurs qui fournissent du contenu numérique et par les consommateurs qui le demandent. Pour différencier facilement ces rôles, il peut être plus facile de considérer l’éditeur dans un rôle serveur et le consommateur dans un rôle client. Par ailleurs, il est important de se rappeler qu’en dehors de ces rôles conceptuels, le service de distribution par les pairs est un véritable système homologue, comme l’indique la possibilité pour tout nœud de distribution d’homologues de publier et de consommer du contenu numérique. Les API de la plateforme de distribution d’homologues sont exposées aux éditeurs et aux consommateurs par une bibliothèque d’importation Win32 (PeerDist.Lib).
Le cycle de vie du contenu fourni par un éditeur et récupéré par un consommateur avec le service peer distribution se compose des opérations suivantes :
| Description | |
|---|---|
| Publication de contenu | La publication est effectuée pour produire une description du contenu appelée Informations de contenu, ou Informations de contenu en abrégé. Ces informations de contenu peuvent ensuite être utilisées par un instance du service peer distribution pour authentifier et reconstruire le contenu. Lorsque du contenu est publié par une application dans le service de distribution homologue, qui est conceptuellement une opération côté serveur, ce contenu est associé à l’identité du serveur de publication, qui est basée sur le SID de l’utilisateur associé au jeton d’accès de thread. Cette liaison est effectuée pour limiter l’accès au contenu par des entités non autorisées. Toutefois, il est important de noter que l’accès aux informations de contenu équivaut à l’accès au contenu lui-même, car les informations de contenu peuvent être utilisées pour obtenir le contenu à partir d’homologues ou d’un cache hébergé. Il existe une nouvelle version de la structure des données d’informations de contenu dans Windows 8 ; toutefois, la version précédente est toujours prise en charge. Pour interagir avec les clients Windows 7, un administrateur peut configurer le service peer distribution pour utiliser la version précédente de la structure des données d’informations sur le contenu. |
| Récupération de contenu | Pour qu’un consommateur puisse récupérer du contenu à partir du service de distribution homologue, l’accès doit être fourni aux informations de contenu publiées associées à ce contenu. Le service de distribution par les pairs utilisé pour publier le contenu peut fournir les informations de contenu associées. Une fois que le consommateur dispose des informations de contenu, d’autres API de distribution d’homologues peuvent être utilisées pour demander du contenu à partir du service de distribution homologue. Le service peer distribution tente de récupérer le contenu à partir du réseau local. Si le contenu n’est pas disponible, l’application cliente est responsable de la récupération du contenu à partir du serveur source. |
| Suppression de publication | Pour les applications qui ont publié du contenu dans le service peer distribution, la fonction PeerDistServerUnpublish a été fournie pour autoriser la non publication du contenu. Une fois que le contenu a été non publié, le service de distribution par homologue local ne fournit plus les informations de contenu associées à ce contenu. |
Complétions asynchrones
L’API de distribution d’homologues prend en charge un modèle d’API asynchrone et, par conséquent, les API de distribution d’homologues autorisent l’utilisation de ports d’achèvement d’E/S ou d’événements comme mécanismes de signalisation pour le traitement des achèvements d’opérations de distribution d’homologues asynchrones. Pour l’un ou l’autre des mécanismes, la distribution d’homologues utilise une structure CHEVAUCHEMENT. En général, peer distribution prend la propriété d’une structure CHEVAUCHEMENT ET de tous les paramètres que le client transmet aux fonctions d’API asynchrones. Le client ne doit pas accéder à ces ressources tant que la fonction asynchrone particulière n’est pas terminée. Dès que les fonctions asynchrones se terminent, le service de distribution d’homologues n’a plus besoin d’accéder à ces ressources et elles peuvent être réutilisées comme l’application appelante le juge bon.
Il n’y aura pas d’achèvement asynchrone si la fonction retourne un code d’erreur autre que ERROR_IO_PENDING. Le retour d’une valeur autre que ERROR_IO_PENDING signifie que l’appel a échoué de façon synchrone. Si l’API de distribution d’homologues retourne ERROR_IO_PENDING, l’appelant doit attendre l’achèvement asynchrone.
Le code d’erreur de l’achèvement asynchrone peut être récupéré de l’une des deux manières suivantes :
Saisie semi-automatique basée sur le port d’achèvement d’E/S
L’utilisateur appelle le mécanisme de port d’achèvement d’E/S en fournissant un handle de port d’achèvement et une clé d’achèvement aux fonctions API suivantes :
PeerDistRegisterForStatusChangeNotification
PeerDistServerPublishStream
PeerDistServerOpenContentInformation
PeerDistClientOpenContent
L’utilisateur crée un port d’achèvement en appelant CreateIoCompletionPort. Ce handle de port d’achèvement peut être utilisé simultanément pour d’autres opérations d’E/S asynchrones ainsi que pour des opérations spécifiques à la distribution d’homologues.
L’appelant doit utiliser la fonction GetQueuedCompletionStatus pour gérer l’achèvement asynchrone. Si l’opération asynchrone échoue, la fonction GetQueuedCompletionStatus retourne FALSE et GetLastError retourne le code d’erreur approprié. L’appelant doit ignorer tous les champs de la structure CHEVAUCHEMENT SI le code d’erreur est autre que ERROR_SUCCESS. L’opération asynchrone réussit si la fonction GetQueuedCompletionStatus retourne TRUE.
Pour plus d’informations, consultez Ports d’achèvement d’E/S.
Complétion basée sur les événements
Si l’appelant définit un handle d’événement valide sur le champ hEvent de la structure OVERLAPPED , peer distribution l’utilise pour signaler que l’opération d’E/S asynchrone associée est terminée.
Un appelant de thread peut gérer les opérations qui se chevauchent en spécifiant un handle à l’objet d’événement de réinitialisation manuelle de la structure OVERLAPPED dans l’une des fonctions d’attente. Une fois l’événement signalé, l’appelant doit appeler PeerGetOverlappedResult en passant dans la structure OVERLAPPED appropriée. PeerGetOverlappedResult retourne FALSE et l’appelant doit appeler GetLastError pour récupérer le code d’erreur. L’appelant doit ignorer tous les champs de la structure CHEVAUCHEMENT SI le code d’erreur est autre que ERROR_SUCCESS. L’opération asynchrone réussit si la fonction PeerGetOverlappedResult retourne TRUE.
Si l’appelant fournit un port d’achèvement avec un événement, l’événement est utilisé comme mécanisme d’achèvement.
Windows 7 : Utilisez la fonction GetOverlappedResult au lieu de PeerGetOverlappedResult.