W_TCP_OFFLOAD_RECEIVE_HANDLER fonction de rappel (ndischimney.h)

Article
02/07/2025

[La fonctionnalité de déchargement de cheminée TCP est déconseillée et ne doit pas être utilisée.]

NDIS appelle la fonction MiniportTcpOffloadReceive pour publier des demandes de réception (tampons de réception) sur une connexion TCP déchargée.

Syntaxe

W_TCP_OFFLOAD_RECEIVE_HANDLER WTcpOffloadReceiveHandler;

NDIS_STATUS WTcpOffloadReceiveHandler(
  [in] IN NDIS_HANDLE MiniportAdapterContext,
  [in] IN PVOID MiniportOffloadContext,
  [in] IN PNET_BUFFER_LIST NetBufferList
)
{...}

Paramètres

[in] MiniportAdapterContext

Handle vers une zone de contexte allouée à une cible de déchargement dans laquelle la cible de déchargement conserve les informations d’état sur cette instance de l’adaptateur. Le pilote miniport a fourni cette poignée à NDIS lorsqu’il a appelé NdisMSetMiniportAttributes à partir de son fonction MiniportInitializeEx.

[in] MiniportOffloadContext

Pointeur vers un emplacement de mémoire qui contient une valeur PVOID. Cette valeur PVOID fait référence au contexte de déchargement miniport qui contient l’objet d’état de la connexion TCP sur laquelle les demandes de réception sont publiées. La cible de déchargement a fourni cette valeur PVOID lorsqu’elle a déchargé l’objet d’état de connexion TCP.

[in] NetBufferList

Pointeur vers une structure NET_BUFFER_LIST. Cette structure peut être une structure autonome ou la première structure d’une liste liée de structures NET_BUFFER_LIST. Chaque structure NET_BUFFER_LIST de la liste décrit une structure NET_BUFFER. La structure NET_BUFFER est mappée à une chaîne de listes de descripteurs de mémoire (MDL). Les NET_BUFFER_LIST et les structures associées sont verrouillées afin qu’elles restent résident dans la mémoire physique. Toutefois, ils ne sont pas mappés à la mémoire système.

Valeur de retour

NDIS_STATUS_PENDING est la seule valeur de retour autorisée. Une cible de déchargement se termine toujours (retourne) les demandes de réception publiées de façon asynchrone en appelant NdisTcpOffloadReceiveComplete.

Remarques

Une application cliente peut publier des demandes sur une connexion TCP déchargée. La cible de déchargement utilise ces demandes pour transférer les données reçues sur la connexion à l’application cliente. Si les demandes de réception sont publiées sur une connexion, la cible de déchargement doit toujours les utiliser pour transférer des données reçues sur la connexion. Pour plus d’informations, consultez 'algorithme de remise.

Le déchargement cible met en file d’attente les structures de NET_BUFFER_LIST publiées en premier dans l’ordre de premier sorti (FIFO). La cible de déchargement utilise le membre MiniportReserved de chaque structure NET_BUFFER_LIST pour mettre en file d’attente la structure.

Chaque structure NET_BUFFER_LIST passée à la fonction MiniportTcpOffloadReceiveRece ive n’a qu’une seule structure NET_BUFFER associée.

La cible de déchargement doit placer les données dans les demandes de réception publiées dans l’ordre FIFO. Autrement dit, les données reçues en premier doivent être placées dans la première demande de réception publiée, et ainsi de suite.

La pile hôte sérialise les appels à la fonction MiniportTcpOffloadReceive par connexion. La pile hôte n’appelle pas la fonction MiniportTcpOffloadReceiveRece ive sur une connexion alors qu’un appel à la fonction MiniportTcpOffloadReceive sur cette connexion est en cours. Cela garantit que les demandes de réception sont toujours publiées dans l’ordre correct dans la fonction MiniportTcpOffloadReceive d’une cible de déchargement.

Notez toutefois que la pile hôte peut appeler la fonction MiniportTcpOffloadReceive sur une connexion avant que la cible de déchargement n’ait terminé un ou plusieurs appels précédents à la fonction MiniportTcpOffloadReceive sur cette même connexion. Notez également que la pile hôte peut appeler la fonction MiniportTcpOffloadRece ive d’une cible de déchargement sur une connexion, tandis qu’un ou plusieurs appels à la fonction MiniportTcpOffloadReceive sont en cours sur une autre connexion.

Une demande de réception publiée peut éventuellement se trouver dans l’un des deux modes suivants :

Mode Push
Mode non push

Notez qu’une cible de déchargement doit prendre en charge à la fois le mode push et le mode non vide. .

Pour déterminer le mode dans lequel se trouve une mémoire tampon, une cible de déchargement appelle la macro NET_BUFFER_LIST_INFO pour obtenir la valeur de TcpReceiveNoPush. Si la valeur est TRUE, la demande de réception est en mode non-embuscade.

Si la demande de réception est en mode Push, la cible de déchargement récupère la valeur de TcpReceiveBytesTransferred en appelant la macro NET_BUFFER_LIST_INFO. Si cette valeur n’est pas zéro, la cible de déchargement démarre immédiatement le minuteur push pour la connexion. Si cette valeur est égale à zéro, la cible de déchargement démarre le minuteur push pour la connexion dès que la cible de déchargement place le premier octet de données de réception dans la demande de réception. La cible de déchargement termine toujours immédiatement les demandes de réception remplies. La cible de déchargement termine une demande de réception partiellement remplie en mode Push si l’une des opérations suivantes se produit :

Le minuteur push expire.
La cible de déchargement reçoit un segment TCP sur la connexion dont le bit PSH est défini.

Si la demande de réception est en mode non vide, la cible de déchargement ne démarre pas un minuteur push. La cible de déchargement termine la demande de réception uniquement lorsque la demande de réception est remplie. La cible de déchargement ignore le bit PSH dans les segments TCP qu’il reçoit sur la connexion.

Si les données sont reçues sur une connexion déchargée pendant l’exécution du minuteur push, la cible de déchargement doit redémarrer le minuteur push pour cette connexion.