W_TCP_OFFLOAD_RECEIVE_HANDLER función de devolución de llamada (ndischimney.h)

Artículo
08/07/2023

[La característica de descarga de chimenea TCP está en desuso y no se debe usar.]

NDIS llama a la función MiniportTcpOffloadReceive para publicar solicitudes de recepción (búferes de recepción) en una conexión TCP descargada.

Sintaxis

W_TCP_OFFLOAD_RECEIVE_HANDLER WTcpOffloadReceiveHandler;

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

Parámetros

[in] MiniportAdapterContext

Identificador de un área de contexto asignada de destino de descarga en la que el destino de descarga mantiene información de estado sobre esta instancia del adaptador. El controlador de minipuerto proporcionó este identificador a NDIS cuando llamó NdisMSetMiniportAttributes de su Función MiniportInitializeEx .

[in] MiniportOffloadContext

Puntero a una ubicación de memoria que contiene un valor PVOID. Este valor PVOID hace referencia al contexto de descarga de miniporte que contiene el objeto de estado de la conexión TCP en la que se publican las solicitudes de recepción. El destino de descarga proporcionó este valor PVOID cuando descargó el objeto de estado de conexión TCP.

[in] NetBufferList

Puntero a una estructura NET_BUFFER_LIST . Esta estructura puede ser una estructura independiente o la primera estructura de una lista vinculada de NET_BUFFER_LIST estructuras. Cada estructura NET_BUFFER_LIST de la lista describe una estructura NET_BUFFER . La estructura NET_BUFFER se asigna a una cadena de listas de descriptores de memoria (MDL). La NET_BUFFER_LIST y las estructuras asociadas están bloqueadas para que permanezcan residentes en la memoria física. Sin embargo, no se asignan a la memoria del sistema.

Valor devuelto

NDIS_STATUS_PENDING es el único valor devuelto permitido. Un destino de descarga siempre se completa (devuelve) las solicitudes de recepción publicadas de forma asincrónica mediante una llamada a . NdisTcpOffloadReceiveComplete.

Comentarios

Una aplicación cliente puede publicar solicitudes de recepción en una conexión TCP descargada. El destino de descarga usa estas solicitudes para transferir los datos recibidos en la conexión a la aplicación cliente. Si las solicitudes de recepción se publican en una conexión, el destino de descarga siempre debe usarlos para transferir los datos que se reciben en la conexión. Para obtener más información, consulte Algoritmo de entrega.

El destino de descarga pone en cola las estructuras de NET_BUFFER_LIST publicadas en primer lugar, primero en salir (FIFO). El destino de descarga usa el miembro MiniportReserved de cada estructura de NET_BUFFER_LIST para poner en cola la estructura.

Cada estructura NET_BUFFER_LIST pasada a la función MiniportTcpOffloadReceive tiene solo una estructura NET_BUFFER asociada.

El destino de descarga debe colocar los datos de recepción en las solicitudes de recepción publicadas en el orden FIFO. Es decir, los datos que se recibieron primero deben colocarse en la primera solicitud de recepción publicada, etc.

La pila de hosts serializa las llamadas a la función MiniportTcpOffloadReceive por conexión. La pila de hosts no llamará a la función MiniportTcpOffloadReceive en una conexión mientras una llamada a la función MiniportTcpOffloadReceive en esa conexión está en curso. Esto garantiza que las solicitudes de recepción siempre se publiquen en el orden correcto para la función MiniportTcpOffloadReceive de un destino de descarga.

Sin embargo, tenga en cuenta que la pila de hosts puede llamar a la función MiniportTcpOffloadReceive en una conexión antes de que el destino de descarga haya completado una o varias llamadas anteriores a la función MiniportTcpOffloadReceive en esa misma conexión. Tenga en cuenta también que la pila de hosts puede llamar a la función MiniportTcpOffloadReceive de un destino de descarga en una conexión mientras una o varias llamadas a la función MiniportTcpOffloadReceive están en curso en otra conexión.

Una solicitud de recepción publicada puede estar opcionalmente en cualquiera de los dos modos:

Modo de inserción
Modo no emboscado

Tenga en cuenta que un destino de descarga debe admitir el modo de inserción y el modo no de descarga. .

Para determinar en qué modo está un búfer, un destino de descarga llama a la macro NET_BUFFER_LIST_INFO para obtener el valor de TcpReceiveNoPush. Si el valor es TRUE, la solicitud de recepción está en modo que no es de emboscada.

Si la solicitud de recepción está en modo de inserción, el destino de descarga recupera el valor de TcpReceiveBytesTransferred llamando a la macro NET_BUFFER_LIST_INFO. Si este valor es distinto de cero, el destino de descarga inicia inmediatamente el temporizador de inserción para la conexión. Si este valor es cero, el destino de descarga inicia el temporizador de inserción para la conexión en cuanto el destino de descarga coloca el primer byte de los datos de recepción en la solicitud de recepción. El destino de descarga siempre completa las solicitudes de recepción rellenadas inmediatamente. El destino de descarga completa una solicitud de recepción parcialmente rellena que está en modo de inserción si se produce alguna de las siguientes acciones:

El temporizador de inserción expira.
El destino de descarga recibe un segmento TCP en la conexión que tiene establecido el bit PSH.

Si la solicitud de recepción está en modo no de descarga, el destino de descarga no inicia un temporizador de inserción. El destino de descarga completa la solicitud de recepción solo cuando se rellena la solicitud de recepción. El destino de descarga omite el bit de PSH en segmentos TCP que recibe en la conexión.

Si se reciben datos en una conexión descargada mientras se ejecuta el temporizador de inserción, el destino de descarga debe reiniciar el temporizador de inserción para esa conexión.