Share via


Canaux

Cette rubrique est spécifique à la technologie héritée assurant la compatibilité descendante avec des applications existantes et n'est pas recommandée en cas de nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF)

Les canaux sont des objets qui transportent des messages entre des applications dans les limites de communication à distance entre des domaines d'application, des processus ou des ordinateurs. Un canal peut écouter les messages entrants sur un point de terminaison, envoyer des messages sortants à un autre point de terminaison ou les deux. Vous pouvez ainsi incorporer une large variété de protocoles, même si le common language runtime n'est pas à l'autre extrémité du canal.

Les canaux doivent implémenter l'interface IChannel, qui fournit des propriétés informatives, telles que ChannelName et ChannelPriority. Les canaux conçus pour écouter un protocole particulier sur un port spécifique implémentent IChannelReceiver et les canaux conçus pour envoyer des informations implémentent IChannelSender. Les objets TcpChannel et HttpChannel implémentent ces deux interfaces, ils peuvent donc être utilisés pour envoyer ou recevoir des informations.

Vous pouvez inscrire des canaux auprès de l'infrastructure de communication à distance de plusieurs façons :

  • Si vous publiez un objet accessible à distance, appelez ChannelServices.RegisterChannel avant d'inscrire votre objet serveur.

  • Si vous consommez les fonctionnalités d'un objet accessible à distance, appelez RegisterChannel avant de créer une instance de votre objet serveur.

Les canaux peuvent également être chargés à partir du fichier de configuration de communication à distance. Pour plus d'informations, consultez Configuration.

Côté client, les messages sont transmis à la chaîne du récepteur de canal cliente après avoir traversé la chaîne de contexte cliente. Le premier récepteur de canal est généralement un récepteur de formateur qui sérialise le message en flux qui est ensuite passé au récepteur de transport client, via la chaîne du récepteur de canal. Le récepteur de transport client écrit ensuite ce flux et le transmet.

Côté serveur, le récepteur de transport serveur lit les demandes provenant de la connexion et passe le flux de demande à la chaîne du récepteur de canal serveur. Le récepteur de formateur serveur à la fin de cette chaîne désérialise la demande en message. Il passe alors ce message à l'infrastructure de communication à distance. Pour plus d'informations sur les récepteurs de canal, consultez Récepteurs et chaînes de récepteurs.

Règles de canal

Lorsqu'un client appelle une méthode sur un objet distant, les paramètres et les autres détails en rapport avec l'appel sont amenés à l'objet distant via le canal. Tous les résultats de l'appel sont retournés de la même façon. Un client peut sélectionner n'importe quel canal inscrit sur le serveur pour communiquer avec l'objet distant, permettant de cette façon aux développeurs de sélectionner les canaux les plus adaptés à leurs besoins. Il est également possible de personnaliser les canaux existants ou de générer de nouveaux canaux qui utilisent un protocole de communication différent. La sélection de canal est soumise aux règles suivantes :

  • Au moins un canal doit être inscrit auprès du système de communication à distance sur le serveur avant qu'un objet distant ne puisse être appelé. Les canaux doivent être inscrits avant les objets. Si un canal n'est pas inscrit sur le client, le système de communication à distance en choisit ou en crée un pour envoyer des appels sortants.

    dkfd3wha.note(fr-fr,VS.100).gifRemarque :
    Si le client attend une fonction de rappel, un canal d'écoute doit être inscrit sur le client et le serveur doit être configuré pour utiliser un canal compatible.

  • Les canaux sont inscrits par domaine d'application. Un processus unique peut contenir plusieurs domaines d'application. Lorsqu'un processus se termine, tous les canaux qu'il a inscrits sont automatiquement détruits.

  • Les noms des canaux doivent être uniques dans un domaine d'application. Par exemple, étant donné que les canaux par défaut ont des noms, vous devez modifier les noms des canaux avant d'inscrire deux objets HttpChannel à un domaine d'application, L'exemple de code C# suivant illustre ceci.

    IDictionary prop = new Hashtable();
    prop["name"] = "http1";
    prop["port"] = "9001";
    ChannelServices.RegisterChannel(new HttpChannel(prop, null, null));
    
  • Vous ne pouvez inscrire qu'une seule fois un canal qui écoute sur un port spécifique. Bien que les canaux soient inscrits par domaines d'application, deux domaines d'application différents situés sur le même ordinateur ne peuvent pas inscrire le même canal s'il écoute sur le même port.

  • Si vous ne savez pas vraiment si un port est disponible, utilisez 0 (zéro) lors de la configuration du port de votre canal pour laisser le système de communication à distance choisir un port disponible pour vous.

  • Les clients peuvent communiquer avec un objet distant via n'importe quel canal inscrit. Le système de communication à distance garantit que l'objet distant est connecté au bon canal lorsqu'un client essaie de se connecter à l'objet. Le client est chargé d'appeler ChannelServices.RegisterChannel avant d'essayer de communiquer avec un objet distant. S'il attend une fonction de rappel, le client doit inscrire un canal et un port.

Lorsqu'un client appelle une méthode sur un proxy, l'appel est intercepté, incorporé à un message et passé à une instance de la classe RealProxy. La classe RealProxy transfère le message au récepteur de messages pour qu'il soit traité. Un récepteur de messages établit une connexion avec le canal inscrit par l'objet distant et distribue le message via le canal dans le domaine d'application émetteur. Le message y est démarshalé et l'appel est effectué sur l'objet distant lui-même.

Lorsque la communication à distance initialise un proxy à un objet distant du domaine client, un récepteur de messages capable de communiquer avec l'objet distant est récupéré à partir canal configuré par le client en appelant IChannelSender.CreateMessageSink sur le canal sélectionné.

Certains aspects de la relation entre canaux et objets distants peuvent rendre perplexe. Par exemple, la manière dont un objet distant WellKnownObjectMode.SingleCall écoute les clients se connecter, si l'objet n'est activé que lorsqu'un appel arrive.

Ceci est possible en partie, car les objets distants partagent des canaux; un objet distant ne possédant pas de canal propre. Les applications serveur qui hébergent des objets distants doivent inscrire les canaux qu'elles requièrent ainsi que les objets qu'elles exposent auprès du système de communication à distance. Lorsqu'un canal est inscrit, il commence automatiquement à écouter le port spécifié et attend les demandes du client. Dans le cas d'appels synchrones, la connexion du client est maintenue pour la durée de l'appel de message. Puisque chaque connexion cliente est gérée dans son propre thread, un canal unique peut s'occuper de plusieurs clients simultanément.

Voir aussi

Référence

HttpChannel
TcpChannel

Concepts

Choix d'un canal
Formateurs de sérialisation
Récepteurs et chaînes de récepteurs

Autres ressources

Vue d'ensemble de .NET Framework Remoting