Manipulação de pipe assíncrono do lado do cliente

Antes de fazer uma chamada remota assíncrona, o cliente deve primeiro inicializar o identificador assíncrono. Assim como acontece com procedimentos de não pipe, o cliente chama uma função assíncrona com o identificador assíncrono como o primeiro parâmetro e usa o identificador assíncrono para enviar e receber dados de pipe, consultar o status da chamada e receber a resposta.

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

O cliente envia dados de pipe assíncronos chamando a função push no pipe assíncrono apropriado, com 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 no identificador assíncrono e se as APCs forem usadas como o mecanismo de notificação, um APC será enfileirado quando o envio do pipe for realmente concluído. Você pode aproveitar esse mecanismo para implementar o controle de fluxo. No entanto, observe que, se o cliente enviar por push outro buffer antes da conclusão do push anterior, o cliente poderá, dependendo da velocidade da operação de transferência, receber apenas uma notificação de envio completo, em vez de uma notificação para cada buffer ou cada operação de push . Quando o cliente envia todos os dados de pipe, ele faz uma chamada por push final com o número de elementos definido como 0.

O programa cliente recebe dados de pipe assíncronos chamando a função de 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 de 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 APC RpcReceiveComplete do tempo de execução antes de chamar pull novamente.