Fonction RxCeSend (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 sur cette opération d’envoi par le transport. Notez qu’il s’agit uniquement d’une demande envoyée au transport. Le transport peut uniquement prendre en charge 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 données doivent être envoyées avant toutes les demandes d’envoi normales que le transport contient actuellement en file d’attente pour la 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 indicateur au transport sous-jacent qu’il ne s’attend pas à une réponse à cet envoi à partir de son homologue à nœud distant. Cet indicateur doit désactiver la 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 de TDI_SEND_NO_RESPONSE_EXPECTED.
RXCE_SEND_NON_BLOCKING
Si le transport sous-jacent n’a actuellement pas d’espace tampon interne disponible pour les données 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 n’envoient pas de mémoire tampon en interne. Notez que RXCE_SEND_NON_BLOCKING équivaut à l’indicateur de TDI_SEND_NON_BLOCKING.
RXCE_SEND_PARTIAL
Signifie si une RX_MEM_DESC(MDL) doit être envoyée dans son intégralité ou si seules des parties 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 revient 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
Le contexte est repassé à 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 de retour
RxCeSend retourne STATUS_SUCCESS en cas de réussite ou l’un des codes d’erreur suivants en cas d’échec :
| Retourner le code | Description |
|---|---|
|
Un circuit virtuel ou une connexion non valide ou déconnecté a été spécifié |
|
L’allocation de la mémoire du pool non paginé nécessaire par cette routine a échoué. |
|
Une longueur non valide a été passée dans le paramètre SendLength en fonction du SendOptions spécifié. |
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 synchrones, cette routine sera également l’IRP et les ressources gratuites allouées une fois la routine terminée.
Les options asynchrones et synchrones indiquées dans le paramètre SendOptions utilisé dans RxCeSend faire la distinction entre deux situations. Dans le cas asynchrone, le contrôle revient à l’appelant une fois la demande 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 revient 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 l’état retourné correspond à l’état d’achèvement 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 existe très peu de différences entre les deux options.
Exigences
| Exigence | Valeur |
|---|---|
| plateforme cible | Bureau |
| d’en-tête | rxce.h (include Rxce.h, Tdi.h) |
| IRQL | <= APC_LEVEL |