Peer Channel Chat
L'exemple de conversation montre comment implémenter une application de conversation entre plusieurs parties à l'aide du canal homologue. Les messages envoyés par les instances d'une application de conversation sont reçus par toutes les autres instances.
Cet exemple n'est pas basé sur le concept de client et de service. Il s'agit d'une application d'égal à égal réelle dans laquelle chaque instance agit comme un homologue d'autres instances. Chaque instance peut envoyer des messages à d'autres instances et recevoir des messages d'autres instances à l'aide du contrat duplex IChat
.
Cet exemple est basé sur l'exemple Self-Host. Par ailleurs, consultez Getting Started, exemple pour une vue d'ensemble détaillée de Windows Communication Foundation (WCF).
Remarque : |
---|
La procédure d'installation ainsi que les instructions de génération relatives à cet exemple figurent à la fin de cette rubrique. |
Concepts clés :
Le canal homologue (Peer Channel) est une technologie de communication P2P (peer-to-peer) entre plusieurs parties de WCF. Elle fournit un canal de communication P2P basé sur des messages sécurisé et évolutif pour les développeurs d'applications. Un exemple courant d'application entre plusieurs parties pouvant bénéficier du canal homologue concerne une application collaborative telle que la conversation, dans le cadre de laquelle un groupe de personnes discutent les unes avec les autres d'égal à égal sans qu'un serveur soit nécessaire. Le canal homologue permet la collaboration P2P, la distribution de contenu, l'équilibrage de charge et le traitement distribué des scénarios consommateur et d'entreprise.
Peer Channel introduit les nouveaux concepts suivants :
Une maille est une collection nommée (un graphique interconnecté) de nœuds homologues qui peuvent communiquer entre eux et qui sont tous identifiés par un ID de maille unique.
Remarque : Les nœuds actifs dans la maille publient leur nom de maille afin de permettre aux autres de les identifier. Une maille présente les caractéristiques suivantes : elle s'ajuste aux modifications apportées à l'appartenance, dispose d'une connectivité résiliente dans un environnement où les nœuds rejoignent et quittent constamment la maille, et est optimisée de manière dynamique en fonction des modèles de trafic. Un nœud homologue est un point de terminaison dans une maille. Une application unique peut disposer de nœuds homologues participant à différentes mailles.
Un programme de résolution d'homologue est chargé de résoudre un ID de maille aux adresses de point de terminaison des nœuds dans la maille. Un nœud homologue utilise ces adresses pour se connecter à d'autres nœuds dans la maille. Les messages peuvent ainsi être propagés sur l'ensemble de la maille.
La conversation est une application console. Chaque instance d'une application de conversation crée un IDuplexChannel avec la même adresse de point de terminaison. Par conséquent, un message envoyé par une instance d'une application de conversation sur son canal homologue est reçu par toutes les autres instances (car elles utilisent toutes la même adresse).
L'application de conversation définit et implémente le contrat duplex IChat
. Le contrat IChat
autorise uniquement les opérations monodirectionnelles car ServiceModel ne prend pas en charge le paradigme demande unique/réponses multiples (dans le cas d'un canal pluripartite, une demande unique envoyée à la maille peut générer plusieurs réponses).
Cet exemple implémente une fonction principale statique pour créer IClientChannel avec le contrat duplex IChat
et à l'aide du point de terminaison spécifié dans le fichier de configuration.
Toutes les instances de conversation doivent utiliser la même adresse de point de terminaison pour garantir que les messages envoyés par une instance sont reçus par toutes les autres.
Les instances de conversation dans cette d'exemple s'identifient entre elles via un programme de résolution personnalisé ou le programme de résolution d'homologue par défaut (PNRP). Notez que PNRP n'est pas disponible sous Windows Server 2003. Par conséquent, un programme de résolution personnalisé doit être utilisé pour exécuter cet exemple sur un système qui exécute Windows Server 2003. Par défaut, cet exemple est configuré pour utiliser un programme de résolution personnalisé. L'utilisation d'un programme de résolution personnalisé ou de celui par défaut dépend du point de terminaison de conversation défini dans le fichier de configuration suivant. Pour basculer sur le programme de résolution d'homologue par défaut (PNRP), remplacez "BindingCustomResolver" par "BindingDefault" sous bindingConfiguration dans le fichier de configuration de l'exemple.
<!-- chat instance participating in the mesh -->
<endpoint name="ChatEndpoint"
address="net.p2p://chatMesh/ServiceModelSamples/Chat"
binding="netPeerTcpBinding"
bindingConfiguration="BindingCustomResolver"
contract="Microsoft.ServiceModel.Samples.IChat">
</endpoint>
Pour que le nœud homologue communique avec le service Peer Channel Custom Peer Resolver, la configuration côté client du Peer Channel Custom Peer Resolver est définie dans le fichier de configuration.
<!-- Client used to communicate with the custom resolver service. -->
<client>
<endpoint configurationName="CustomPeerResolverEndpoint"
address="net.tcp://localhost/ServiceModelsamples/peerResolverService"
binding="netTcpBinding"
bindingConfiguration="Binding3"
contract="Microsoft.ServiceModel.SamplesICustomPeerResolver">
</endpoint>
</client>
L'adresse identifie celle du service de programme de résolution. Si le service de programme de résolution s'exécute sur un ordinateur distant, remplacez localhost
par un nom de domaine complet.
L'exemple montre également comment récupérer le nœud homologue de IClientChannel et comment s'inscrire aux événements en ligne et hors connexion à l'aide de IOnlineStatus. Un événement en ligne est initialisé lorsque le nœud homologue est connecté à au moins un autre nœud homologue dans la maille. Un événement hors connexion est initialisé lorsque le nœud homologue n'est plus connecté à aucun autre nœud homologue dans la maille.
Actuellement, les métadonnées ne peuvent pas être générées car un canal homologue n'est pas intégré avec l'utilitaire de métadonnées de service (Svcutil.exe).
Lorsque vous exécutez l'exemple, les messages de conversation envoyés par une instance de conversation s'affichent dans les fenêtres de console d'autres instances de conversation. Appuyez sur la touche Q puis sur ENTER dans chaque fenêtre de console pour arrêter l'instance.
Remarque : |
---|
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
Assurez-vous d'avoir effectué la procédure indiquée dans la section Procédure d'installation unique pour les exemples Windows Communication Foundation.
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.
Pour exécuter l'exemple dans une configuration à un ou plusieurs ordinateurs, suivez les instructions indiquées dans Exécution des exemples Windows Communication Foundation.
En outre, les étapes suivantes s'appliquent pour l'exemple de conversation. Chaque fois que l'étape 3 fait référence au client et au service, ces étapes s'appliquent à de instances distinctes de l'exemple (car l'exemple de conversation n'est pas basé sur le concept de client et de service).
Si bindingConfiguration a la valeur BindingDefault, assurez-vous que PNRP est installé et activé sur tous les ordinateurs utilisés. Si bindingConfiguration a la valeur BindingCustomResolver, assurez-vous que le service de programme de résolution personnalisé situé dans le répertoire Chat\<langue>\CustomerResolver\bin du répertoire Chat project/solution est démarré sur tous les ordinateurs utilisés.
Démarrez le nombre souhaité d'instances de l'application. Entrez tout d'abord un pseudonyme qui distinguera les messages envoyés à partir d'une instance client spécifique. Une fois ce nom entré, les messages de conversation peuvent être envoyés à la maille. Ces messages doivent être reproduits en écho à toutes les autres instances avec un nom de membre distinct (autrement dit, un message provenant d'un client portant le même nom ne sera pas affiché, et le propre message d'un client unique ne sera pas reproduit en écho à la console).
Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.