Gestion asynchrone des canaux côté client

Avant d’effectuer un appel à distance asynchrone, le client doit d’abord initialiser le handle asynchrone. Comme pour les procédures non pipe, le client appelle une fonction asynchrone avec le handle asynchrone comme premier paramètre et utilise le handle asynchrone pour envoyer et recevoir des données de canal, interroger la status de l’appel et recevoir la réponse.

Le client effectue l’appel de procédure distante asynchrone avec le handle asynchrone comme premier paramètre. Le client peut utiliser ce handle pour interroger le status de l’appel et recevoir la réponse. Le modèle de canal asynchrone est symétrique. Les applications clientes et serveur envoient et reçoivent activement des données de canal (par opposition au RPC synchrone, où les données de canal sont envoyées et reçues passivement).

Le client envoie des données de canal asynchrones en appelant la fonction push sur le canal asynchrone approprié, avec la variable d’état du canal comme premier paramètre. Lorsque la fonction push retourne, le client peut modifier ou libérer la mémoire tampon d’envoi.

Si l’indicateur RPC_ASYNC_NOTIFY_ON_SEND_COMPLETE est défini dans le handle asynchrone et si les API sont utilisés comme mécanisme de notification, un APC est mis en file d’attente lorsque l’envoi du canal est effectivement terminé. Vous pouvez tirer parti de ce mécanisme pour implémenter le contrôle de flux. Notez toutefois que si le client envoie une autre mémoire tampon avant la fin du push précédent, le client ne peut, en fonction de la vitesse de l’opération de transfert, recevoir qu’une seule notification d’envoi complet, plutôt qu’une notification pour chaque mémoire tampon ou chaque opération push . Lorsque le client a envoyé toutes les données du canal, il effectue un dernier appel push avec le nombre d’éléments défini sur 0.

Le programme client reçoit les données de canal asynchrones en appelant la fonction pull sur le canal asynchrone approprié, avec la variable d’état du canal comme premier paramètre. Si aucune donnée de canal n’est disponible, la fonction pull retourne RPC_S_ASYNC_CALL_PENDING.

Si le mécanisme de notification est APC et que le serveur a renvoyé RPC_S_ASYNC_CALL_PENDING, le client doit attendre qu’il reçoive l’APC RpcReceiveComplete de l’exécution avant d’appeler à nouveau pull .