Função RxCeSend (rxce.h)

RxCeSend envia uma TSDU (unidade de dados do serviço de transporte) ao longo da conexão especificada em um circuito virtual.

Sintaxe

NTSTATUS RxCeSend(
  [in] IN PRXCE_VC pVc,
  [in] IN ULONG    SendOptions,
  [in] IN PMDL     pMdl,
  [in] IN ULONG    SendLength,
  [in] IN PVOID    pCompletionContext
);

Parâmetros

[in] pVc

Um ponteiro para o circuito virtual ao longo do qual o TSDU deve ser enviado.

[in] SendOptions

As opções desejadas para transmitir os dados nessa operação de envio pelo transporte. Observe que essa é apenas uma solicitação enviada para o transporte. O transporte só pode dar suporte a um número limitado das opções especificadas e ignorar opções sem suporte. O parâmetro SendOptions consiste em um conjunto de bits definido em rxce.h. O parâmetro SendOptions pode ser uma combinação dos seguintes bits:

RXCE_SEND_EXPEDITED

Os dados determinados devem ser enviados antes de qualquer solicitação de envio normal que o transporte esteja mantendo na fila para transmissão nessa conexão ponto a ponto de extremidade. Se o transporte não der suporte a transferências aceleradas, ele poderá ignorar esse sinalizador. Observe que RXCE_SEND_EXPEDITED é equivalente ao sinalizador de TDI_SEND_EXPEDITED TDI.

RXCE_SEND_NO_RESPONSE_EXPECTED

O chamador está dando uma dica ao transporte subjacente de que não espera uma resposta a esse envio de seu par de nós remotos. Esse sinalizador deve desabilitar o piggybacking da confirmação de TSDU pelo transporte de nó remoto. Observe que RXCE_SEND_NO_RESPONSE_EXPECTED é equivalente ao sinalizador TDI_SEND_NO_RESPONSE_EXPECTED.

RXCE_SEND_NON_BLOCKING

Se o transporte subjacente atualmente não tiver espaço de buffer interno disponível para os dados fornecidos, ele deverá apenas concluir o IRP com STATUS_DEVICE_NOT_READY. Se o transporte tiver algum espaço em buffer disponível, ele deverá copiar o máximo de dados possível do buffer fornecido pelo cliente, definir o membro IoStatus.Information com o número de bytes copiados e concluir o IRP com STATUS_SUCCESS.

Esse sinalizador é irrelevante para transportes que não armazenam em buffer enviados internamente. Observe que RXCE_SEND_NON_BLOCKING é equivalente ao sinalizador TDI_SEND_NON_BLOCKING.

RXCE_SEND_PARTIAL

Significa se um RX_MEM_DESC (MDL) deve ser enviado em sua totalidade ou se apenas partes dele precisam ser enviadas. Essa opção solicita que o transporte permita que a operação de envio transmita parte dos dados se o transporte e o MDL permitirem esse comportamento.

RXCE_SEND_SYNCHRONOUS

Significa se a operação de envio deve transmitir os dados de forma síncrona. Quando essa opção é definida, a solicitação é enviada para o transporte subjacente e o controle não retorna ao chamador até que a solicitação seja concluída. Observe que o parâmetro pCompletionContext é ignorado quando esse bit é definido.

[in] pMdl

Um ponteiro para o buffer a ser enviado.

[in] SendLength

O comprimento dos dados a serem enviados.

[in] pCompletionContext

O contexto passado de volta para o chamador durante SendCompletion para operações assíncronas. Não que esse parâmetro seja ignorado se o parâmetro SendOptions solicitar uma operação de envio síncrona.

Retornar valor

RxCeSend retorna STATUS_SUCCESS com êxito ou um dos seguintes códigos de erro em caso de falha:

Comentários

A rotina RxCeSend alocará o IRP, criará a solicitação de envio para o driver de transporte subjacente e enviará a solicitação à TDI. No caso de operações de envio síncronas, essa rotina também será o IRP gratuito e os recursos alocados quando a rotina for concluída.

As opções assíncronas e síncronas indicadas no parâmetro SendOptions usado em RxCeSend distinguem entre duas situações. No caso assíncrono, o controle retorna ao chamador depois que a solicitação é enviada com êxito ao transporte subjacente. Os resultados de qualquer solicitação específica são comunicados novamente usando a rotina de retorno de chamada SendCompletion . O parâmetro pCompletionContext em RxCeSend é passado de volta na rotina de retorno de chamada para ajudar o chamador a desambiguar as solicitações.

No caso síncrono, a solicitação é enviada para o transporte subjacente e o controle não retorna ao chamador até que a solicitação seja concluída. Observe que, no caso síncrono, o parâmetro pCompletionContext é ignorado e o status retornado corresponde ao status de conclusão das operações.

O benefício das opções assíncronas e síncronas depende do transporte subjacente. Em um ambiente de circuito virtual (TCP, por exemplo), uma opção síncrona implica que o controle não retorna até que os dados cheguem ao servidor. Por outro lado, para transportes orientados a datagrama (UDP, por exemplo), há muito pouca diferença entre as duas opções.

Requisitos

Confira também

MDL

RxCeSendDatagram