Compartir a través de


Control de canalizaciones asincrónicas del lado cliente

Antes de realizar una llamada remota asincrónica, el cliente debe inicializar primero el identificador asincrónico. Al igual que con los procedimientos que no son de pippe, el cliente llama a una función asincrónica con el identificador asincrónico como primer parámetro y usa el identificador asincrónico para enviar y recibir datos de canalización, consultar el estado de la llamada y recibir la respuesta.

El cliente realiza la llamada de procedimiento remoto asincrónico con el identificador asincrónico como primer parámetro. El cliente puede usar este identificador para consultar el estado de la llamada y recibir la respuesta. El modelo de canalización asincrónica es simétrico. Las aplicaciones cliente y servidor envían y reciben datos de canalización activamente (en lugar de RPC sincrónico, donde los datos de canalización se envían y reciben pasivamente).

El cliente envía datos de canalización asincrónica llamando a la función push en la canalización asincrónica adecuada, con la variable de estado de la canalización como primer parámetro. Cuando la función push devuelve, el cliente puede modificar o liberar el búfer de envío.

Si la marca de RPC_ASYNC_NOTIFY_ON_SEND_COMPLETE se establece en el identificador asincrónico y si las API se usan como mecanismo de notificación, se pone en cola un APC cuando el envío de canalización se completa realmente. Puede aprovechar este mecanismo para implementar el control de flujo. Sin embargo, tenga en cuenta que si el cliente inserta otro búfer antes de que se complete la inserción anterior, el cliente puede, dependiendo de la velocidad de la operación de transferencia, recibir solo una notificación de envío completa, en lugar de una notificación para cada búfer o cada operación de inserción . Cuando el cliente ha enviado todos los datos de canalización, realiza una llamada de inserción final con el número de elementos establecidos en 0.

El programa cliente recibe datos de canalización asincrónica llamando a la función de extracción en la canalización asincrónica adecuada, con la variable de estado de la canalización como primer parámetro. Si no hay datos de canalización disponibles, la función de extracción devuelve RPC_S_ASYNC_CALL_PENDING.

Si el mecanismo de notificación es APC y el servidor devolvió RPC_S_ASYNC_CALL_PENDING, el cliente debe esperar hasta que reciba rpcReceiveComplete APC desde el tiempo de ejecución antes de llamar a pull de nuevo.