Manuseio assíncrono de tubos do lado do cliente

Antes de fazer uma chamada remota assíncrona, o cliente deve primeiro inicializar o identificador assíncrono. Como nos procedimentos não relacionados a pipes, o cliente chama uma função assíncrona com o identificador assíncrono como o primeiro parâmetro e utiliza esse identificador para enviar e receber dados do canal, interrogar o estado da chamada e receber a resposta.

O cliente faz a chamada de procedimento remoto assíncrono usando o identificador assíncrono como primeiro parâmetro. O cliente pode usar esse identificador para consultar o status da chamada e receber a resposta. O modelo de tubo assíncrono é simétrico. Os aplicativos cliente e servidor enviam e recebem dados de pipe ativamente (em oposição ao RPC síncrono, onde os dados de pipe são enviados e recebidos passivamente).

O cliente envia dados em pipe assíncrono chamando a função push no pipe assíncrono apropriado, tendo a variável de estado do pipe como o primeiro parâmetro. Quando a função push retorna, o cliente pode modificar ou liberar o buffer de envio.

Se o sinalizador RPC_ASYNC_NOTIFY_ON_SEND_COMPLETE estiver definido na alça assíncrona e se os APCs forem usados como mecanismo de notificação, um APC será enfileirado quando o envio do pipe estiver realmente concluído. Você pode aproveitar esse mecanismo para implementar o controle de fluxo. Observe, no entanto, que se o cliente enviar outro buffer antes que o push anterior seja concluído, o cliente poderá, dependendo da velocidade da operação de transferência, receber apenas uma notificação de envio concluído, em vez de uma notificação para cada buffer ou cada operação de push . Quando o cliente envia todos os dados do canal, o cliente realiza uma última chamada push com o número de elementos definido para 0.

O programa cliente recebe dados de pipe assíncronos chamando a função pull no pipe assíncrono apropriado, com a variável de estado do pipe como o primeiro parâmetro. Se nenhum dado de pipe estiver disponível, a função pull retornará RPC_S_ASYNC_CALL_PENDING.

Se o mecanismo de notificação for APC e o servidor retornar RPC_S_ASYNC_CALL_PENDING, o cliente deverá aguardar até receber o RpcReceiveComplete APC do ambiente de execução antes de chamar pull novamente.