Gestion des ensembles de connexions réseau (associations)

À compter de Windows 2000, le temps d’exécution RPC peut maintenir plusieurs connexions entre le client et le serveur. Cela facilite l’opération sur les transports qui ne prennent pas en charge la modification de l’identité du client sans rétablir la connexion, les clients multithreads et les clients asynchrones. L’ensemble de connexions entre un processus client et un point de terminaison de serveur est appelé association dans la terminologie RPC. La compréhension des associations peut améliorer l’implémentation de RPC.

Dans un scénario d’identité à un seul thread et à client unique, RPC ouvre une connexion entre un processus client et un point de terminaison de serveur pour effectuer des appels RPC. Lorsqu’un appel RPC synchrone est effectué, le client envoie la demande au serveur sur cette connexion et reçoit également la réponse. Lorsque le nombre de threads effectuant des appels RPC dans le processus client augmente, l’identité de sécurité du client peut changer. Lorsque les appels asynchrones/de canal sont mélangés à des appels synchrones sur le client, rpc peut nécessiter plusieurs connexions réseau. Toutes les connexions de l’ensemble sont placées dans un pool de connexions appelé association.

Un appel de procédure distante synchrone utilise exclusivement une connexion donnée pour se conformer aux normes RPC. Une connexion utilisée par un appel RPC synchrone est considérée comme occupée si une demande a été envoyée, mais qu’aucune réponse n’a été reçue. Aucun autre trafic n’est autorisé sur cette connexion tant que la réponse n’est pas reçue. Le temps d’exécution RPC tente de multiplex asynchrone et de canaliser les appels RPC sur la même connexion. Les appels synchrones et asynchrones/de canal ne peuvent pas être mélangés sur la même connexion, ce qui signifie qu’une connexion donnée peut être utilisée pour les appels RPC synchrones ou pour les appels RPC asynchrones/de canal.

RPC tente de réutiliser de manière agressive les connexions à partir du pool. Lorsqu’un nouvel appel RPC est effectué, RPC tente de trouver une connexion appropriée à partir du pool et crée une nouvelle connexion uniquement si une connexion appropriée est introuvable. Pour qu’une connexion soit considérée comme appropriée, elle doit :

• Être du type approprié (synchrone ou asynchrone/canal).
• Soyez libre.
• Avoir la même identité de sécurité que le handle de liaison sur lequel l’appel est effectué. Si le suivi dynamique des identités est utilisé, l’identité du handle de liaison est actualisée à partir du jeton de thread au début de l’appel. Si le suivi d’identité statique est utilisé, l’identité client marquée sur le handle de liaison est utilisée.

Une fois l’appel terminé, une fois la réponse reçue, la connexion est marquée comme étant libre et peut être utilisée pour d’autres appels RPC.

L’identité de sécurité d’une connexion ne peut pas changer. Par exemple, si un grand nombre d’appels au même serveur sont effectués sous des identités de sécurité différentes, le nombre de connexions dans le pool de threads augmente. L’association elle-même compte les références et, lorsque toutes les références ont disparu, elle arrête et ferme toutes les connexions. Chaque handle de liaison et chaque handle de contexte contiennent une référence sur l’association. Lorsque tous sont fermés, l’association disparaît. Sur Windows XP, les associations ne disparaissent pas nécessairement immédiatement ; ils peuvent rester pendant une courte période (la période cible est de 20 secondes, mais le temps d’exécution RPC peut choisir de retarder la destruction de l’association si aucun thread n’est disponible pour exécuter la tâche). Si vous ne souhaitez pas que l’association reste active après la fermeture du dernier handle/handle de liaison de contexte, utilisez l’option RPC_C_OPT_DONT_LINGER pour forcer le runtime RPC à fermer immédiatement la connexion.