W_TCP_OFFLOAD_RECEIVE_HANDLER función de devolución de llamada (ndischimney.h)
[La característica de descarga de chimenea TCP está en desuso y no debe usarse].
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 estructuras de NET_BUFFER_LIST. 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 completa (devuelve) las solicitudes de recepción publicadas de forma asincrónica mediante una llamada a NdisTcpOffloadReceiveComplete.
Observaciones
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 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 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 en, 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 de NET_BUFFER_LIST que se pasa 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 pedido FIFO. Es decir, los datos recibidos 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 se llama a la función MiniportTcpOffloadReceive en esa conexión. Esto garantiza que las solicitudes de recepción siempre se publiquen en el orden correcto para una función miniportTcpOffloadReceive de 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
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 no emboscado.
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 no es cero, el destino de descarga inicia inmediatamente el del temporizador de inserción de 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 llena 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 los datos se reciben 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.
Requisitos
| Requisito | Valor |
|---|---|
| de la plataforma de destino de | Windows |
| encabezado de | ndischimney.h (incluya Ndischimney.h) |
| irQL | Cualquier nivel |