RxCeSend, fonction (rxce.h)

RxCeSend envoie une unité de données de service de transport (TSDU) le long de la connexion spécifiée sur un circuit virtuel.

Syntaxe

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

Paramètres

[in] pVc

Pointeur vers le circuit virtuel le long duquel le TSDU doit être envoyé.

[in] SendOptions

Options souhaitées pour transmettre les données de cette opération d’envoi par le transport. Notez qu’il s’agit uniquement d’une requête envoyée au transport. Le transport ne peut prendre en charge qu’un nombre limité d’options spécifiées et ignorer les options non prises en charge. Le paramètre SendOptions se compose d’un ensemble de bits définis dans rxce.h. Le paramètre SendOptions peut être une combinaison des bits suivants :

RXCE_SEND_EXPEDITED

Les données données doivent être envoyées avant toutes les demandes d’envoi normales que le transport conserve actuellement en file d’attente pour transmission sur cette connexion de point de terminaison à point de terminaison. Si le transport ne prend pas en charge les transferts accélérés, il peut ignorer cet indicateur. Notez que RXCE_SEND_EXPEDITED équivaut à l’indicateur de TDI_SEND_EXPEDITED TDI.

RXCE_SEND_NO_RESPONSE_EXPECTED

L’appelant donne un indice au transport sous-jacent qu’il n’attend pas de réponse à cet envoi à partir de son homologue de nœud distant. Cet indicateur doit désactiver le piggybacking de l’accusé de réception TSDU par le transport de nœud distant. Notez que RXCE_SEND_NO_RESPONSE_EXPECTED équivaut à l’indicateur TDI_SEND_NO_RESPONSE_EXPECTED.

RXCE_SEND_NON_BLOCKING

Si le transport sous-jacent n’a actuellement aucun espace de mémoire tampon interne disponible pour les données données, il doit simplement terminer l’IRP avec STATUS_DEVICE_NOT_READY. Si le transport dispose d’un espace de mémoire tampon disponible, il doit copier autant de données que possible à partir de la mémoire tampon fournie par le client, définir le membre IoStatus.Information sur le nombre d’octets qu’il a copiés et terminer l’IRP avec STATUS_SUCCESS.

Cet indicateur n’est pas pertinent pour les transports qui ne souhaitent pas mettre en mémoire tampon les envois en interne. Notez que RXCE_SEND_NON_BLOCKING équivaut à l’indicateur TDI_SEND_NON_BLOCKING.

RXCE_SEND_PARTIAL

Indique si un RX_MEM_DESC(MDL) doit être envoyé dans son intégralité, ou si seules des parties de celle-ci doivent être envoyées. Cette option demande que le transport autorise l’opération d’envoi à transmettre une partie des données si le transport et MDL autorisent ce comportement.

RXCE_SEND_SYNCHRONOUS

Indique si l’opération d’envoi doit transmettre les données de manière synchrone. Lorsque cette option est définie, la demande est envoyée au transport sous-jacent et le contrôle ne retourne pas à l’appelant tant que la demande n’est pas terminée. Notez que le paramètre pCompletionContext est ignoré lorsque ce bit est défini.

[in] pMdl

Pointeur vers la mémoire tampon à envoyer.

[in] SendLength

Longueur des données à envoyer.

[in] pCompletionContext

Contexte passé à l’appelant pendant SendCompletion pour les opérations asynchrones. Ce paramètre n’est pas ignoré si le paramètre SendOptions demande une opération d’envoi synchrone.

Valeur retournée

RxCeSend retourne STATUS_SUCCESS en cas de réussite ou l’un des codes d’erreur suivants en cas d’échec :

Remarques

La routine RxCeSend alloue l’IRP, génère la demande d’envoi pour le pilote de transport sous-jacent et envoie la demande à TDI. Dans le cas d’opérations d’envoi synchrone, cette routine sera également l’IRP gratuit et les ressources allouées une fois la routine terminée.

Les options asynchrones et synchrones indiquées dans le paramètre SendOptions utilisé dans RxCeSend distinguent deux situations. Dans le cas asynchrone, le contrôle retourne à l’appelant une fois que la demande a été correctement envoyée au transport sous-jacent. Les résultats d’une requête donnée sont communiqués à l’aide de la routine de rappel SendCompletion . Le paramètre pCompletionContext dans RxCeSend est repassé dans la routine de rappel pour aider l’appelant à lever l’ambiguïté des requêtes.

Dans le cas synchrone, la demande est envoyée au transport sous-jacent et le contrôle ne retourne pas à l’appelant tant que la demande n’est pas terminée. Notez que dans le cas synchrone, le paramètre pCompletionContext est ignoré et le status retourné correspond à l’achèvement status des opérations.

L’avantage des options asynchrones et synchrones dépend du transport sous-jacent. Dans un environnement de circuit virtuel (TCP, par exemple), une option synchrone implique que le contrôle ne retourne pas tant que les données n’atteignent pas le serveur. En revanche, pour les transports orientés datagrammes (UDP, par exemple), il y a très peu de différence entre les deux options.

Configuration requise

Voir aussi

MDL

RxCeSendDatagram