Spécification de séquences de protocoles

Les applications serveur doivent sélectionner une ou plusieurs séquences de protocole à utiliser lors de la communication avec le client via le réseau. Le choix des séquences de protocole dépend du réseau. Consultez Interprétation des informations de liaison et sélection d’une séquence de protocole.

Votre programme serveur peut autoriser les clients à se connecter à l’aide de n’importe quelle séquence de protocole prise en charge par le réseau. Pour ce faire, appelez RpcServerUseAllProtseqs et passez RPC_C_PROTSEQ_MAX_REQS_DEFAULT comme premier paramètre. Toutefois, ce n’est pas l’approche recommandée. Au lieu de cela, l’utilisation de ncalrpc pour les appels locaux et les ncacn_ip_tcp ou ncacn_http pour les appels distants est généralement suffisante. Les réseaux hétérogènes sont rares et pratiquement tous les réseaux prennent en charge TCP/IP.

Si vous souhaitez que votre client limite l’allocation de ports pour les points de terminaison dynamiques à une plage de ports spécifique, appelez RpcServerUseAllProtseqsEx à la place. Cette fonction est spécifique à Microsoft RPC et est extrêmement utile pour les appels de procédure distante qui passent par un pare-feu. Il utilise un paramètre supplémentaire pour passer des indicateurs de contrôle d’allocation de port à la fonction. Consultez Configuration du Registre pour les allocations de ports et la liaison sélective.

Vous pouvez spécifier des séquences de protocole et des informations de point de terminaison dans votre fichier MIDL lorsque vous développez les interfaces du serveur. Dans ce cas, votre serveur doit utiliser RpcServerUseAllProtseqsIf pour inscrire toutes les séquences de protocole et les informations de point de terminaison associées fournies dans le fichier IDL. En outre, il existe une fonction RpcServerUseAllProtseqsIfEx correspondante qui permet également au serveur de passer des indicateurs de contrôle d’allocation de port.

Si vous souhaitez configurer vos programmes client et serveur pour communiquer avec une séquence de protocole spécifiée, l’application serveur doit appeler RpcServerUseProtseq. Pour obtenir la liste complète des séquences de protocoles Microsoft RPC, consultez Constantes de séquence de protocole.

Microsoft RPC fournit également RpcServerUseProtseqEx pour permettre aux applications de sélectionner des séquences de protocole spécifiques et de contrôler l’allocation de ports dynamiques.

En plus des protocoles orientés connexion, Microsoft RPC prend également en charge les protocoles de datagramme (sans connexion). Les protocoles orientés connexion sont recommandés ; Les protocoles de datagramme ont des ensembles de fonctionnalités différents des protocoles orientés connexion et ne doivent être utilisés que si un développeur de système distribué a besoin d’une fonctionnalité disponible uniquement dans les protocoles de datagramme. Voici quelques-unes des fonctionnalités disponibles lors de l’utilisation de protocoles de datagramme :

• Les datagrammes prennent en charge les protocoles de transport sans connexion UDP et IPX.
• Étant donné qu’il n’est pas nécessaire d’établir et de maintenir une connexion, le protocole RPC du datagramme nécessite moins de surcharge de ressources.
• Les datagrammes permettent une liaison plus rapide.
• Comme avec rpc orienté connexion, les appels RPC de datagramme sont par défaut non monodémpotents. Cela signifie que l’appel n’est pas exécuté plusieurs fois. Toutefois, une fonction peut être marquée comme idempotente dans le fichier IDL indiquant à RPC qu’il est inoffensif d’exécuter la fonction plusieurs fois en réponse à une seule requête cliente. Cela permet au temps d’exécution de conserver moins d’état sur le serveur. Notez qu’un appel idempotent ne serait réexécuté que dans de rares circonstances sur un réseau instable.
• Datagram RPC prend en charge l’attribut IDL de diffusion . La diffusion permet à un client d’émettre des messages à plusieurs serveurs en même temps. Cela permet au client de localiser l’un des serveurs disponibles sur le réseau ou de contrôler plusieurs serveurs simultanément. Notez que la diffusion du datagramme est valide uniquement dans le lien local et qu’elle ne traverse généralement pas les routeurs. Les appels de diffusion sont implicitement idempotents. Si l’appel contient des paramètres [out], seule la première réponse du serveur est retournée. Une fois qu’un serveur répond, tous les futurs RPC sur ce handle de liaison seront envoyés à ce serveur uniquement, y compris les appels avec l’attribut de diffusion. Pour envoyer une autre diffusion, créez un nouveau handle de liaison ou appelez RpcBindingReset sur le handle existant.
• Datagram RPC prend en charge l’attribut IDL peut-être . Cela permet au client d’envoyer un appel au serveur sans attendre une réponse ou une confirmation. L’appel ne peut pas contenir de paramètres [out]. Les appels utilisant les appels [peut-être] sont implicitement idempotents.