Maintien de l’état sur le serveur entre les appels

Il est souvent nécessaire de maintenir l’état sur le serveur entre des appels RPC distincts. L’utilisation de handles de contexte est la meilleure façon de le faire. Quelques mots sur la façon dont les gestions de contexte fonctionnent en interne vous aident à comprendre quand les handles de contexte fonctionnent le mieux.

Le client ne reçoit jamais l’état conservé sur le serveur. Le plus souvent, l’état sur le serveur est un pointeur vers un bloc de mémoire et le client ne dispose d’aucune information à ce sujet. Tout ce que le client reçoit est un grand nombre unique, avec d’autres informations associées, que le serveur envoie au client et qui représente le handle de contexte dans toutes les opérations suivantes. Chaque fois que le client fait référence à un handle ouvert, il envoie le grand nombre qu’il a reçu du serveur lors de l’ouverture de ce handle de contexte.

Le serveur effectue le suivi de tous les grands nombres qu’il envoie à un client. Lorsque le serveur reçoit un grand nombre représentant un handle de contexte, il recherche le nombre dans la collection de handles de contexte valides et en suspens pour ce client et recherche le contexte côté serveur correspondant à un grand nombre donné. Cela est passé à la routine du serveur. Si le grand nombre est introuvable, une exception RPC_X_SS_CONTEXT_MISMATCH est levée et propagée au client.

Les corollaires de cette conception sont les suivants :

• Un handle de contexte est valide uniquement dans le contexte de la session client/serveur existante. Il ne peut pas être transmis à un autre client.
• Un handle de contexte devient non valide si le serveur est redémarré ou perd sa connexion au client.
• Le client ne peut pas interpréter ce que représente le handle de contexte sur le serveur. Pour un client, tous les handles de contexte sont simplement de grands nombres.

Si le client échoue, le serveur reçoit une notification et propre ses handles de contexte à l’aide du mécanisme d’exécution.