W_TCP_OFFLOAD_RECEIVE_HANDLER fonction de rappel (ndischimney.h)

Article
08/07/2023

[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 (mémoires 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 de la cible de déchargement dans laquelle la cible de déchargement conserve des informations d’état sur cette instance de l’adaptateur. Le pilote miniport a fourni ce handle à 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 de miniport qui contient l’objet d’état pour 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 mémoire (MDL). Les NET_BUFFER_LIST et les structures associées sont verrouillées afin qu’elles restent résidentes dans la mémoire physique. Toutefois, elles ne sont pas mappées dans la mémoire système.

Valeur retournée

NDIS_STATUS_PENDING est la seule valeur de retour autorisée. Une cible de déchargement effectue toujours (retourne) les demandes de réception publiées de manière asynchrone en appelant NdisTcpOffloadReceiveComplete.

Remarques

Une application cliente peut publier des demandes de réception 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 les données reçues sur la connexion. Pour plus d’informations, consultez Algorithme de remise.

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

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

La cible de déchargement doit placer les données de réception dans les demandes de réception publiées dans l’ordre FIFO. Autrement dit, les données qui ont été 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 MiniportTcpOffloadReceive sur une connexion pendant 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 le bon ordre sur 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 ait effectué 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 MiniportTcpOffloadReceive d’une cible de déchargement sur une connexion pendant qu’un ou plusieurs appels à la fonction MiniportTcpOffloadReceive sont en cours sur une autre connexion.

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

Mode Push
Mode sans erreur

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

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-feu.

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 égale à 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 les demandes de réception remplies immédiatement. La cible de déchargement termine une demande de réception partiellement remplie qui est 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 pour laquelle 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 de 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’elle reçoit sur la connexion.

Si des 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.