Constantes d’option de liaison
Les applications définissent les constantes d’option de liaison pour contrôler la façon dont la bibliothèque d’exécution RPC traite les appels de procédure distante. Le tableau suivant répertorie chaque propriété de liaison et les valeurs constantes pertinentes pour les propriétés de liaison.
Notes
Toutes les options de file d’attente de messages (MQ) du tableau suivant sont valides pour Windows 2000 uniquement. Windows XP et les versions ultérieures ne prennent pas en charge la mise en file d’attente des messages. Les développeurs sont découragés d’utiliser la mise en file d’attente de messages.
| Constante/valeur | Description |
|---|---|
|
Par défaut. Si la valeur est FALSE, classement des appels causals. Les appels RPC sont exécutés dans un ordre strict de soumission. Consultez la section Notes. Si la valeur est TRUE, l’ordre des appels noncausaux. Les appels RPC sont exécutés indépendamment. Consultez la section Notes. |
|
Non nécessaire pour les programmes d’application. Utilisé en interne par Microsoft. |
|
Non nécessaire pour les programmes d’application. Utilisé en interne par Microsoft. |
|
Si la valeur est TRUE, un ID de session est généré pour chaque connexion. |
|
Si la valeur est TRUE, l’authentification basée sur les cookies côté client est utilisée pour les connexions. Un pointeur vers la structure RPC_C_OPT_COOKIE_AUTH_DESCRIPTOR est passé en tant que paramètre OptionValue dans RpcBindingSetOption. |
|
Non nécessaire pour les programmes d’application. Utilisé en interne par Microsoft. |
|
Si la valeur est TRUE, forcez l’arrêt de l’association une fois que le dernier handle de liaison/handle de contexte est libéré. |
|
Lorsqu’il est défini sur true, RPC ne réutilise pas les connexions existantes. Un handle de liaison unique est ouvert pour chaque connexion et l’état est conservé pour chaque handle de liaison unique. |
Notes
Par défaut, la bibliothèque d’exécution RPC exécute les appels sur un handle de liaison donné à partir de chaque thread d’une application dans un ordre strict de soumission. Cela ne garantit pas que les appels de différents threads sur le même handle de liaison sont sérialisés. Les applications multithread doivent sérialiser leurs appels RPC. Si ce comportement est trop restrictif, vous pouvez activer l’ordre non décausal. Dans ce cas, la bibliothèque d’exécution RPC exécute les appels indépendamment. Il n’impose aucun ordre à leur soumission.
Un exemple d’application qui peut trouver utile l’ordre non décausal est un programme multithread dont les threads effectuent des appels sur le même handle de liaison. De même, un programme qui utilise plusieurs appels asynchrones sur un handle de liaison trouvera l’ordre non décausal une option pratique. Un autre exemple peut être un programme proxy Internet qui utilise un thread unique pour gérer les demandes pour plusieurs clients. Dans chacun de ces cas, il serait extrêmement restrictif d’essayer de sérialiser les appels de procédure distante.
L’option RPC_C_OPT_DONT_LINGER peut être définie uniquement sur les handles de liaison qui utilisent les séquences de protocole ncalrpc ou ncacn_*. Il ne peut pas être utilisé sur les séquences de protocole ncadg_* . La fonction RpcBindingSetOption avec cette option doit être appelée sur un handle de liaison sur lequel au moins un appel RPC a été effectué. Si aucun appel RPC n’a été effectué sur le handle de liaison, RPC_S_WRONG_KIND_OF_BINDING est retourné à partir de l’appel de fonction RpcBindingSetOption . L’option prend effet pour l’ensemble de l’association, quel que soit le nombre de poignées de liaison attachées à l’association. Étant donné qu’elle est vérifiée avant la destruction de l’association, elle peut être définie à tout moment avant la fermeture du handle de liaison.
Spécifications
| Condition requise | Valeur |
|---|---|
| Client minimal pris en charge |
Windows 2000 Professionnel [applications de bureau uniquement] |
| Serveur minimal pris en charge |
Windows 2000 Server [applications de bureau uniquement] |
| En-tête |
|