nl::Weave::Profiles::BDX_Development

Esse manipulador é chamado sempre que é encontrado um erro do Weave que não pode ser retornado diretamente por meio de códigos de erro para o fluxo de controle definido pelo aplicativo pelo usuário.

Ou seja, se ocorrer um erro em outro gerenciador com uma assinatura que tenha o tipo de retorno nulo (por exemplo, em resposta a uma mensagem Weave recebida ou mesmo despachada pelo protocolo), esse gerenciador será chamado para que o usuário possa determinar se a transferência pode ser recuperada e continuar ou se deve chamar Shutdown(). Observe que é possível ocorrer um erro antes que uma BDXTransfer seja inicializada (por exemplo, muitos objetos de transferência alocados). Nesse caso, esse erro será registrado pelo Weave e o protocolo processará a limpeza de qualquer estado necessário alocado.

Get a block of data to be transmitted.

O autor da chamada fornece o espaço de armazenamento em buffer (buffer e comprimento do buffer, transmitidos por referência). O recebedor da chamada (aplicativo do usuário) DEVE usar o buffer fornecido, mas, por motivos de compatibilidade com versões anteriores, pode retornar o próprio buffer. O recebedor da chamada não pode fornecer mais do que o aLength de bytes. Quando retornamos, aLength contém o número real de bytes lidos no buffer.

Processar o bloco de dados apontados por um aDataBlock de comprimento aLength.

Provavelmente, isso envolve gravar em um arquivo e fechar esse arquivo se isLastBlock for verdadeiro.

Callback invocado quando um ReceiveInit enviado anteriormente é aceito pelo destino.

Use essa oportunidade para abrir arquivos ou alocar recursos para a transferência, caso não tenha feito isso ao iniciá-la.

Callback invocado ao receber uma mensagem ReceiveInit.

A função dele é determinar se você deseja aceitar o recebimento e, em caso afirmativo, definir aXfer->mIsAccepted=true para que o protocolo envie uma mensagem de aceitação para o iniciador. O objeto BDXTransfer é iniciado para as configurações padrão. Esse é um bom momento para anexar qualquer estado específico do aplicativo (identificadores de arquivo abertos etc.) a aXfer->mAppState. Também é preciso anexar os gerenciadores necessários para, por exemplo, lidar com blocos ao objeto BDXTransfer. Se um código de erro diferente de kStatus_Success for retornado, presume-se que a transferência foi rejeitada e o protocolo tratará o envio de uma mensagem de rejeição com o código.

Invocado se uma das mensagens Init anteriores foi rejeitada pelo destino.

Callback invocado quando um SendInit enviado anteriormente é aceito pelo destino.

Use essa oportunidade para abrir arquivos ou alocar recursos para a transferência, caso não tenha feito isso ao iniciá-la.

Callback invocado ao receber uma mensagem SendInit.

A função dele é determinar se você quer aceitar o SendInit e, em caso afirmativo, definir aXfer->mIsAccepted=true para que o protocolo envie uma mensagem de aceitação para o iniciador. O objeto BDXTransfer é iniciado para as configurações padrão. Esse é um bom momento para anexar qualquer estado específico do aplicativo (identificadores de arquivo abertos etc.) a aXfer->mAppState. Também é preciso anexar os gerenciadores necessários para, por exemplo, lidar com blocos ao objeto BDXTransfer. Se for retornado um código de erro diferente de WEAVE_NO_ERROR, presume-se que a transferência foi rejeitada e o protocolo processará o envio de uma mensagem de rejeição com o código.

Lidar com casos em que a transferência é concluída.

Gerenciar mensagens TransferError recebidas ou enviadas pelo BDX.

Observação:presume-se que a transferência BDX seja potencialmente recuperável (possivelmente temporária, por exemplo, fora dos pacotes Buffers no momento) e, portanto, a opção de chamar Shutdown() é deixada para o programador do aplicativo e os callbacks definidos. TODO: verifique e reconcilie com a linguagem no documento BDX, que afirma: "[Um TransferError] pode ser enviado a qualquer momento por qualquer uma das partes para encerrar prematuramente a transferência de dados em massa".

GetBDXAckFlag retorna a sinalização adequada para o campo RequestAck, dependendo da conexão do contexto de troca (nenhuma confirmação de solicitação para TCP) e com base no suporte ao tempo de compilação para WRMP.