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 nesta 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 nesta 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 para o transporte subjacente que não espera uma resposta para esse envio de seu par de nós remotos. Esse sinalizador deve desabilitar o retorno da confirmação de TSDU pelo transporte de nó remoto. Observe que RXCE_SEND_NO_RESPONSE_EXPECTED é equivalente ao sinalizador de 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 de buffer disponível, ele deverá copiar o máximo de dados possível do buffer fornecido pelo cliente, definir o membro IoStatus.Information para o número de bytes copiados e concluir o IRP com STATUS_SUCCESS.

Esse sinalizador é irrelevante para transportes que não são enviados internamente pelo buffer. Observe que RXCE_SEND_NON_BLOCKING é equivalente ao sinalizador de 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 precisarem 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 SendOptions parâmetro solicitar uma operação de envio síncrona.

Valor de retorno

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

Observações

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 distinguir entre duas situações. No caso assíncrono, o controle retorna ao chamador depois que a solicitação é enviada com êxito para o transporte subjacente. Os resultados de qualquer solicitação determinada são comunicados novamente usando a rotina de retorno de chamada SendCompletion. O parâmetro pCompletionContext em RxCeSend é passado novamente 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 datagram (UDP, por exemplo), há muito pouca diferença entre as duas opções.

Requisitos

Consulte também

MDL

RxCeSendDatagram