Peer Channel Secure Chat

Cet exemple illustre l'utilisation de la liaison NetPeerTcpBinding avec l'authentification par mot de passe, qui fournit la communication entre plusieurs parties à l'aide du canal homologue. Cet exemple est une variante de Getting Started, exemple. Pour une vue d'ensemble de Windows Communication Foundation (WCF), consultez Getting Started, exemple.

Dans cet exemple, les instances d'application sont des applications console auto-hébergées.

Contrairement à d'autres exemples de liaison de transport, cet exemple utilise l'interface de contrat IChat à des fins d'illustration de la communication pluripartite. Toutes les instances implémentent ce contrat pour recevoir des messages et créer des proxys avec le même contrat afin d'envoyer des messages à la maille. Cela est illustré en créant un DuplexChannel vers la maille.

Remarque :
La procédure d'installation ainsi que les instructions de génération relatives à cet exemple figurent en fin de rubrique.

Le fonctionnement du processus de configuration de liaison dans l'exemple implique les concepts de canal homologue suivants :

• Le programme de résolution d'homologue est chargé de résoudre un ID de maille en adresses de point de terminaison de certains nœuds dans la maille.
• Une maille est une collection nommée de nœuds d'homologue identifiés par l'ID de maille.
• Un nœud d'homologue est une instance d'une application qui participe à la maille.
• Les ID de maille identifient la partie hôte de l'adresse d'un point de terminaison dans la maille. Ces adresses sont par exemple « net.p2p://chatMesh/servicemodelsamples/chat » ou « net.p2p://broadcastMesh/servicemodelsamples/announcements ». chatMesh et broadcastMesh sont les ID de maille.
• Tous les clients qui participent à une maille utilisent le même ID de maille, mais peuvent potentiellement utiliser des chemins d'accès et des services différents. Un message adressé à une adresse de point de terminaison spécifique est remis à tous les canaux homologues utilisant cette adresse.

Lorsqu'un nœud d'homologue est ouvert (suite à l'ouverture du canal homologue), il utilise un programme de résolution d'homologue pour résoudre l'ID de maille en adresses de quelques autres nœuds d'homologue auxquels se connecter. Cela crée une maille de nœuds interconnectés et permet de propager des messages sur l'ensemble de la maille.

PeerTransportCredentialType spécifie la manière dont les homologues dans la maille sont authentifiés les uns par rapport aux autres. Cette propriété peut être spécifiée soit dans la configuration de liaison, dans l'objet NetPeerTcpBinding, soit en utilisant PeerTransportBindingElement. Une instance ClientCredentialSettings (ou ServiceCredentialSettings) avec les informations d'identification appropriées spécifiées sur la propriété Peer doit être ajoutée à la collection de comportements sur la fabrication de canal ou ServiceHost selon l'utilisation.

1. Cet exemple utilise le mode d'authentification par mot de passe pour sécuriser le canal homologue (ce qui représente le mode par défaut). Cela s'effectue en établissant une connexion sécurisée entre des voisins et en échangeant une transformation de ce mot de passe. Lorsque Password est spécifié, la propriété ClientCredentialSettings.Peer doit contenir un mot de passe valide et éventuellement une instance X509Certificate2 (à l'aide de SetSelfCertificate).

La liaison est spécifiée dans le fichier de configuration de l'application. Le type de liaison est spécifié dans l'attribut Binding de l'élément de point de terminaison, comme le montre l'exemple suivant.

<client>
   <!-- chat instance participating in the mesh -->
   <endpoint name="SecureChatEndpoint"
            address="net.p2p://SecureChatMesh/servicemodelsamples/chat"
             binding="netPeerTcpBinding"
             bindingConfiguration="SecureChatBinding"
             contract="Microsoft.ServiceModel.Samples.IChat">
   </endpoint>
 </client>

Si vous utilisez la liaison NetPeerTcpBinding avec le comportement par défaut, la sécurité par mot de passe est activée. L'élément de liaison fournit des attributs permettant de définir le port, l'adresse IP d'écoute, le type de programme de résolution, la taille maximale des messages, la taille maximale du pool de mémoires tampons, les quotas de lecteurs, le mode d'authentification des nœuds d'homologue, l'authentification des messages et les délais d'attente (pour la fermeture, l'ouverture, l'envoi et la réception).

Remarque : cet exemple utilise le programme de résolution d'homologue par défaut (PNRP), qui n'est pas disponible dans Windows Server 2003. Par conséquent, vous devez utiliser un programme de résolution d'homologue personnalisé pour exécuter cet exemple sur Windows Server 2003. Pour un exemple qui utilise un programme de résolution d'homologue personnalisé, consultez Peer Channel Chat.

<netPeerTcpBinding>
   <binding configurationName="Binding1"> 
    <resolver mode="Custom">
       <customResolver 
            type="MyAppNameSpace.MyCustomPeerResolver, myApp"/>
    </resolver>
   </binding>
</netPeerTcpBinding>

Le fichier qui contient MyCustomPeerResolver doit être compilé avec l'application. Notez que si l'exemple est exécuté sur plusieurs ordinateurs avec différentes plateformes, ils doivent tous utiliser le même programme de résolution.

Cette implémentation de conversation montre également comment récupérer le nœud d'homologue associé à l'instance de récepteur ou d'expéditeur et comment s'inscrire aux événements en ligne et hors connexion. Un événement en ligne est déclenché lorsque le nœud d'homologue est connecté à au moins un autre nœud d'homologue dans la maille. Un événement hors connexion est déclenché lorsqu'un nœud d'homologue n'est plus connecté à aucun autre nœud d'homologue dans la maille.

À ce stade, le canal homologue ne s'intègre pas à Service Model Metadata Utility Tool (Svcutil.exe). Pour cette raison, Svcutil.exe ne peut pas être utilisé pour générer un canal typé pour l'expéditeur.

Lorsque vous exécutez l'exemple, le client demande de fournir un surnom et un mot de passe, après quoi il affiche un message indiquant qu'il est prêt à envoyer des messages. Les messages de conversation s'afficheront dans les autres fenêtres de console clientes. Pour arrêter le client, appuyez sur la touche Q, puis sur ENTRÉE dans les fenêtres de console d'un client.

Si vous activez le suivi ou l'enregistrement des messages, vous pouvez surveiller l'activité de l'expéditeur et du récepteur de manière plus approfondie. La section Procédures décrit comment activer le suivi et l'enregistrement des messages.

Remarque :
Il est important de noter que l'exemple ne gère pas actuellement toutes les exceptions possibles que l'infrastructure peut lever. Si vous utilisez ces exemples dans un environnement commercial ou de production, conformez-vous aux meilleures pratiques de gestion des exceptions.

Pour configurer, générer et exécuter l'exemple

1. Assurez-vous d'avoir effectué la Procédure d'installation unique pour les exemples Windows Communication Foundation.

2. Pour générer l'édition C# ou Visual Basic .NET de la solution, suivez les instructions indiquées dans Génération des exemples Windows Communication Foundation.

3. Pour exécuter l'exemple dans une configuration à un seul ordinateur, suivez les instructions indiquées dans Exécution des exemples Windows Communication Foundation.

4. Pour installer PNRP sur Windows XP SP2 (installation unique) :

   1. Dans le Panneau de configuration, double-cliquez sur Ajout/Suppression de programmes.
   2. Dans la boîte de dialogue Ajouter ou supprimer des programmes, cliquez sur Ajouter ou supprimer des composants Windows.
   3. Dans l'Assistant Composants de Windows, activez la case à cocher Services de mise en réseau, puis cliquez sur Détails.
   4. Activez la case à cocher Homologue à homologue, puis cliquez sur OK.
   5. Cliquez sur Suivant dans l'Assistant Composants de Windows.
   6. Lorsque l'installation est terminée, cliquez sur Terminer.
   7. Dans une invite de commandes shell, démarrez le service PNRP à l'aide de la commande suivante : net start pnrpsvc.

5. Démarrez plusieurs instances de l'exemple, en entrant chaque fois un surnom et un mot de passe. Le surnom de chaque client doit être distinct et le mot de passe doit être identique pour toutes les instances. Les messages de conversation envoyés par une instance de l'application sont reçus par toutes les autres instances, à condition que les surnoms soient distincts et le mot de passe identique. Plusieurs clients avec le même surnom sont autorisés, mais les messages de ces clients ne sont pas affichés.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.