W_TCP_OFFLOAD_RECEIVE_HANDLER Rückruffunktion (ndischimney.h)

Artikel
02/07/2025

[Das TCP-Schornstein-Offload-Feature ist veraltet und sollte nicht verwendet werden.]

NDIS ruft die MiniportTcpOffloadReceive-Funktion auf, um Anforderungen (Empfangspuffer) für eine entladene TCP-Verbindung zu posten.

Syntax

W_TCP_OFFLOAD_RECEIVE_HANDLER WTcpOffloadReceiveHandler;

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

Parameter

[in] MiniportAdapterContext

Das Handle für einen kontextbezogenen Offload-Zielbereich, in dem das Offloadziel Zustandsinformationen zu dieser Instanz des Adapters verwaltet. Der Miniporttreiber hat diesen Handle bei aufruften NDIS bereitgestellt. von NdisMSetMiniportAttributes MiniportInitializeEx Funktion.

[in] MiniportOffloadContext

Ein Zeiger auf einen Speicherspeicherort, der einen PVOID-Wert enthält. Dieser PVOID-Wert verweist auf den Miniport-Offloadkontext, der das Statusobjekt für die TCP-Verbindung enthält, für die die Empfangsanforderungen gepostet werden. Das Offload-Ziel hat diesen PVOID-Wert beim Entladen des TCP-Verbindungsstatusobjekts bereitgestellt.

[in] NetBufferList

Ein Zeiger auf eine NET_BUFFER_LIST Struktur. Diese Struktur kann eine eigenständige Struktur oder die erste Struktur in einer verknüpften Liste von NET_BUFFER_LIST Strukturen sein. Jede NET_BUFFER_LIST Struktur in der Liste beschreibt eine NET_BUFFER Struktur. Die NET_BUFFER-Struktur ist einer Kette von Speicherdeskriptorlisten (MDLs) zugeordnet. Die NET_BUFFER_LIST und zugeordneten Strukturen sind gesperrt, sodass sie im physischen Speicher verbleiben. Sie werden jedoch nicht im Systemspeicher zugeordnet.

Rückgabewert

NDIS_STATUS_PENDING ist der einzige zulässige Rückgabewert. Ein offload-Ziel führt immer gepostete Empfangenanforderungen asynchron durch Aufrufen des Aufrufs (Rückgabe) aus. NdisTcpOffloadReceiveComplete.

Bemerkungen

Eine Clientanwendung kann Anforderungen für eine entladene TCP-Verbindung bereitstellen. Das Offloadziel verwendet diese Anforderungen zum Übertragen von Daten, die bei der Verbindung mit der Clientanwendung empfangen wurden. Wenn Empfangsanforderungen für eine Verbindung gepostet werden, sollte das Offloadziel diese immer verwenden, um Daten zu übertragen, die in der Verbindung empfangen werden. Weitere Informationen finden Sie unter Übermittlungsalgorithmus.

Die Offloadzielwarteschlangen werden die bereitgestellten NET_BUFFER_LIST Strukturen zuerst in der FiFO-Reihenfolge (First Out) in die Warteschlange gestellt. Das Offload-Ziel verwendet das MiniportReserved Member jeder NET_BUFFER_LIST Struktur, um die Struktur in die Warteschlange zu stellen.

Jede an die MiniportTcpOffloadReceive Funktion übergebene NET_BUFFER_LIST Struktur weist nur eine NET_BUFFER Struktur zu.

Das Offload-Ziel sollte Daten in die bereitgestellten Empfangsanforderungen in FIFO-Reihenfolge aufnehmen. Das heißt, Daten, die zuerst empfangen wurden, sollten in die erste gepostete Empfangsanfrage gestellt werden usw.

Der Hoststapel serialisiert Aufrufe der MiniportTcpOffloadReceive Funktion pro Verbindung. Der Hoststapel ruft die MiniportTcpOffloadReceive-Funktion für eine Verbindung nicht auf, während ein Aufruf der MiniportTcpOffloadReceive-Funktion für diese Verbindung ausgeführt wird. Dadurch wird sichergestellt, dass empfangene Anforderungen immer in der richtigen Reihenfolge in die MiniportTcpOffloadReceive-Funktion eines Offloadziels gepostet werden.

Beachten Sie jedoch, dass der Hoststapel die MiniportTcpOffloadReceive-Funktion für eine Verbindung aufrufen kann, bevor das Offloadziel einen oder mehrere vorherige Aufrufe an die MiniportTcpOffloadReceive Funktion für dieselbe Verbindung abgeschlossen hat. Beachten Sie auch, dass der Hoststapel die MiniportTcpOffloadReceive- Funktion eines Offloadziels für eine Verbindung aufrufen kann, während ein oder mehrere Aufrufe der MiniportTcpOffloadReceive Funktion in einer anderen Verbindung ausgeführt werden.

Eine bereitgestellte Empfangsanfrage kann optional in einem von zwei Modi vorhanden sein:

Pushmodus
Nicht-Druckmodus

Beachten Sie, dass ein Offloadziel sowohl den Pushmodus als auch den Nichtpush-Modus unterstützen muss. .

Um zu bestimmen, in welchem Modus sich ein Puffer befindet, ruft ein Offloadziel das NET_BUFFER_LIST_INFO Makro auf, um den Wert TcpReceiveNoPush-abzurufen. Wenn der Wert TRUEist, befindet sich die Empfangsanforderung im Nichtpush-Modus.

Wenn sich die Empfangsanforderung im Pushmodus befindet, ruft das Offloadziel den Wert TcpReceiveBytesTransferred- ab, indem das NET_BUFFER_LIST_INFO-Makro aufgerufen wird. Wenn dieser Wert ungleich Null ist, startet das Offload-Ziel sofort den Pushtimer- für die Verbindung. Wenn dieser Wert null ist, startet das Offload-Ziel den Pushtimer für die Verbindung, sobald das Offloadziel das erste Byte des Empfangsdaten in die Empfangsanforderung platziert. Das Offloadziel schließt immer ausgefüllte Empfangsanforderungen sofort ab. Das Offloadziel schließt eine teilweise ausgefüllte Empfangsanforderung ab, die sich im Pushmodus befindet, wenn eine der folgenden Aktionen auftritt:

Der Pushtimer läuft ab.
Das Offloadziel empfängt ein TCP-Segment für die Verbindung, für die der PSH-Bitsatz festgelegt ist.

Wenn sich die Empfangsanforderung im Nichtpush-Modus befindet, startet das Offload-Ziel keinen Pushtimer. Das Offloadziel schließt die Empfangsanforderung nur ab, wenn die Empfangsanforderung ausgefüllt ist. Das Offloadziel ignoriert das PSH-Bit in TCP-Segmenten, die es für die Verbindung empfängt.

Wenn Daten in einer entladenen Verbindung empfangen werden, während der Pushtimer ausgeführt wird, muss das Offloadziel den Pushtimer für diese Verbindung neu starten.