Sémantique des échecs pour les handles de contexte
Cette rubrique traite de la sémantique des échecs pour les handles de contexte.
La sémantique d’échec lors de la fermeture du handle de contexte échoue
Imaginez qu’une application cliente tente de fermer un handle de contexte qu’elle a ouvert sur le serveur, sans arrêter le processus client. En outre, supposons que l’appel au serveur pour fermer le handle de contexte échoue (par exemple, le client manque de mémoire). La bonne façon de gérer cette situation consiste à appeler la fonction RpcSsDestroyClientContext . Dans ce cas, le client nettoie son côté du handle de contexte et ferme la connexion au serveur de manière abandonnée. Étant donné que la connexion est en fait un pool de connexions (voir RPC et le réseau), qui est compté avec une référence pour chaque liaison ou handle de contexte ouvert, la destruction du handle de contexte en appelant la fonction RpcSsDestroyClientContext ne détruit pas réellement la connexion. Au lieu de cela, il décrémente le nombre de références pour le pool de connexions. Pour que les connexions dans le pool soient fermées, le client doit fermer tous les handles de liaison et de contexte à ce serveur à partir du processus client. Ensuite, toutes les connexions dans le pool sont fermées, et le mécanisme d’arrêt du serveur est lancé et nettoyé.
Sémantique d’échec pendant le changement d’état du handle de contexte
Les informations de cette section font référence aux plateformes Windows XP et ultérieures.
Les handles de contexte sont simplement des paramètres d’une fonction. Toutes les modifications apportées à l’état d’un handle de contexte se produisent lorsque les paramètres sont marshalés ou non délimités. Par exemple, si un client ouvre un handle de contexte (le remplace de NULL à non NULL), l’exécution RPC n’ouvre pas réellement la partie RPC du handle tant que les arguments ne sont pas marshalés pour l’envoi au client. Des échecs peuvent se produire pendant l’intervalle. En raison d’une variété de conditions réseau possibles ou de ressources faibles, la transmission du paquet au client peut échouer. Ou la routine serveur peut lever une exception lors de la tentative de modification d’un handle de contexte. Dans ces situations ou dans d’autres situations d’échec, le client et le serveur peuvent obtenir des vues incohérentes du handle de contexte. Cette section explique la règle pour l’état du handle de contexte et la responsabilité du code client et serveur lors de diverses conditions d’échec.
Un handle de contexte NULL arrive, mais la routine serveur rencontre un échec et lève une exception.
Il incombe à la routine du serveur de propre tout état lié au handle de contexte qu’elle a créé. Le temps d’exécution RPC nettoie son état.
Un handle de contexte non NULL arrive, mais la routine serveur rencontre un échec et lève une exception.
Si la routine serveur a fermé le handle de contexte, le client n’en saura pas, car l’appel ne réussit pas ; L’utilisation ultérieure du handle de contexte entraîne une erreur RPC_X_SS_CONTEXT_MISMATCH sur le client. Si la routine serveur ne modifie pas le handle de contexte, le client peut toujours l’utiliser. Si la routine du serveur modifie les informations stockées dans le contexte du serveur, les nouveaux appels du client utilisent ces informations.
Un handle de contexte non NULL arrive et la routine serveur ferme le handle, mais le marshaling après le marshaling a échoué ou le traitement après le marshaling a échoué.
Le handle de contexte est fermé, et d’autres appels de ce client à l’aide de ce handle de contexte entraînent une erreur RPC_X_SS_CONTEXT_MISMATCH sur le client.
Un handle de contexte NULL arrive et le serveur crée son contexte pour ce handle, mais le marshaling après que le handle de contexte a échoué ou le traitement après le marshaling a échoué.
Dans ce cas, l’exécution RPC appelle l’exécution pour ce handle de contexte et nettoie l’état RPC pour ce handle de contexte. Le handle de contexte n’est pas créé côté client.
Un handle de contexte non NULL arrive et le serveur ne modifie pas le handle de contexte, ou il modifie les informations stockées dans le contexte du serveur, et le marshaling échoue une fois le handle de contexte marshalé.
Les nouveaux appels du client utilisent le handle de contexte dont dispose le serveur.
Un handle de contexte NULL arrive et le serveur ne le définit pas sur autre chose que NULL, mais l’appel échoue avant que le handle de contexte ne soit marshalé.
Dans ce cas, aucun handle de contexte n’est créé sur le client.
Un handle de contexte non NULL arrive et le serveur lui affecte la valeur NULL, mais le marshaling échoue avant que le handle de contexte ne soit marshalé.
Dans ce cas, le handle de contexte reste fermé sur le serveur et le client obtient RPC_X_SS_CONTEXT_MISMATCH erreurs lorsqu’il tente d’utiliser le handle de contexte.
Un handle de contexte NULL arrive sur le serveur et le serveur le définit sur non NULL, mais le marshaling échoue avant que le handle de contexte ne soit marshalé.
L’exécution du handle de contexte doit être appelée afin que le serveur puisse propre et qu’aucun handle de contexte ne soit créé sur le client.
Un handle de contexte non NULL arrive, et le serveur ne modifie pas le handle de contexte, ou il modifie les informations stockées dans le contexte du serveur, et le marshaling échoue avant que le handle de contexte ne soit marshalé.
Les nouveaux appels du client utilisent l’état sur le serveur.
Un handle de contexte est déclaré en tant que valeur de retour, et la routine serveur retourne NULL pour le handle de contexte et le marshaling échoue avant que le handle de contexte ne soit marshalé.
Dans ce cas, aucun nouveau contexte n’est créé sur le client.
Un handle de contexte est déclaré en tant que valeur de retour, et la routine serveur retourne une valeur non NULL pour le handle de contexte et le marshaling échoue avant que le handle de contexte ne soit marshalé.
L’exécution RPC appelle la routine d’exécution du handle de contexte pour lui donner la possibilité de propre et aucun nouveau contexte n’est créé sur le client.