функция обратного вызова NDIS_TCP_OFFLOAD_RECEIVE_INDICATE (ndischimney.h)

Статья
02/26/2024

[Функция разгрузки tcp chimney является устаревшей и не должна использоваться.]

Целевой объект разгрузки вызывает функцию NdisTcpOffloadReceiveHandler , чтобы указать, что полученные сетевые данные доступны для использования клиентским приложением.

Синтаксис

NDIS_TCP_OFFLOAD_RECEIVE_INDICATE NdisTcpOffloadReceiveIndicate;

NDIS_STATUS NdisTcpOffloadReceiveIndicate(
  [in]  IN NDIS_HANDLE NdisOffloadHandle,
  [in]  IN PNET_BUFFER_LIST NetBufferList,
  [in]  IN NDIS_STATUS Status,
  [out] OUT PULONG BytesConsumed
)
{...}

Параметры

[in] NdisOffloadHandle

Дескриптор, определяющий разгруженное TCP-подключение, для которого производится указание. При разгрузке подключения этот дескриптор был указан в члене NdisOffloadHandle NDIS_MINIPORT_OFFLOAD_BLOCK_LIST структуры, связанной с состоянием подключения.

[in] NetBufferList

Указатель на структуру NET_BUFFER_LIST . Каждая NET_BUFFER_LIST структура описывает список NET_BUFFER структур. Каждая NET_BUFFER структура в списке сопоставляется с цепочкой списков дескрипторов памяти (MDL). Многомерные списки содержат полученные данные. Многомерные списки заблокированы, чтобы они оставались резидентными, но не сопоставляются с системной памятью.

Структура NET_BUFFER_LIST , определяемая NetBufferList , должна быть автономной и не может быть первой структурой в связанном списке NET_BUFFER_LIST структур. Целевые объекты разгрузки могут обойти это ограничение, связав столько многомерных выражений, сколько необходимо, к одному и тому же NET_BUFFER в индикаторе получения разгрузки.

[in] Status

Целевой объект разгрузки должен содержать следующее значение состояния:

NDIS_STATUS_SUCCESS

Это означает, что стек узлов может сохранять права владения NET_BUFFER_LIST структурами и связанными структурами, пока не вернет эти структуры вФункция MiniportTcpOffloadReceiveReturn целевого объекта разгрузки.

[out] BytesConsumed

Указатель на переменную типа ULONG, получающую количество байтов, использованных клиентским приложением.

Возвращаемое значение

Функция NdisTcpOffloadReceiveHandler может возвращать одно из следующих значений:

Код возврата	Описание
NDIS_STATUS_SUCCESS	Клиентское приложение использовало все указанные данные получения.
NDIS_STATUS_OFFLOAD_DATA_NOT_ACCEPTED	Клиентское приложение отклонило все указанные данные получения.
NDIS_STATUS_OFFLOAD_DATA_PARTIALLY_ACCEPTED	Клиентское приложение использовало подмножество указанных данных получения. Объем данных в байтах, использованный клиентским приложением, возвращается в переменной, заданной параметром BytesConsumed .

Буферы получения отправляются в Функция MiniportTcpOffloadReceive целевого объекта разгрузки. Если для подключения доступны предварительно отложенные запросы на получение (буферы, предоставляемые клиентским приложением), целевой объект разгрузки должен передать данные получения путем вызоваФункция NdisTcpOffloadReceiveComplete. Дополнительные сведения см. в разделе Алгоритм доставки.

Все запросы на получение должны быть выполнены целевым объектом разгрузки (даже если они являются нулевыми).

После того, как целевой объект разгрузки указал получение данных и что данные были отклонены, целевой объект разгрузки не может указывать на эти данные снова, пока стек узлов не опубликует запрос на получение:

Обычные запросы на получение
Если стек узлов отправляет обычные запросы на получение, целевой объект разгрузки должен завершить эти запросы, прежде чем делать какие-либо указания на получение. Дополнительные сведения см. в разделе Алгоритм доставки.
Запросы на получение с нулевыми байтами
Стек узла может отправить нулевой запрос на получение, чтобы включить указания получения целевым объектом разгрузки. Запрос на получение с нулевым байтом — это запрос, в котором значение элемента DataLength (дополнительные сведения см. в разделе NET_BUFFER структуре) равно нулю. Запрос на получение с нулевым байтом не использует буферированные данные.

Во время инициализации целевой объект разгрузки должен выделить два пула буферов, каждый из которых содержит NET_BUFFER_LIST структуры и NET_BUFFER структуры. Целевой объект разгрузки использует один пул для получения показаний через дымоход TCP при вызовеФункция NdisTcpOffloadReceiveHandler. Целевой объект разгрузки использует другой пул для получения показаний через интерфейс NDIS без отправки при вызовеФункция NdisMIndicateReceiveNetBufferLists.

Каждая выделенная NET_BUFFER_LIST структура должна иметь только одну NET_BUFFER структуру, связанную с ней. Количество таких структур, которые необходимо выделить, не может быть задано модулю модуля записи драйверов. Дополнительные сведения о выделении таких структур см. в разделе Управление буфером драйвера miniport.

Если не выполняется отложенное подтверждение, целевой объект разгрузки должен подтвердить получение данных, как только целевой объект разгрузки имеет внутренние буферы, в которые он может поместить данные. Целевой объект разгрузки может подтвердить полученные данные до, во время или после вызова функции NdisTcpOffloadReceiveHandler .

Целевой объект разгрузки всегда предоставляет значение Состояния NDIS_STATUS_SUCCESS при вызове функции NdisTcpOffloadReceiveHandler . Это означает, что стек узлов может сохранить владение NET_BUFFER_LIST структурами и связанными структурами, пока не вернет эти структуры в целевой объект разгрузки.

Если стек узлов возвращает NDIS_STATUS_SUCCESS, указывая, что клиентское приложение приняло и использовало полученные данные, стек узлов вернет структуры NET_BUFFER_LIST вФункция MiniportTcpOffloadReceiveReturn целевого объекта разгрузки. Стек узла установит для переменной, заданной параметром BytesConsumed , число байтов, указанных целевым объектом разгрузки.
Если стек узлов возвращает NDIS_STATUS_NOT_ACCEPTED, указывая, что клиентское приложение отклонило полученные данные, целевой объект разгрузки возобновляет владение указанными структурами NET_BUFFER_LIST при возвращении функции NdisTcpOffloadReceiveHandler . Целевой объект разгрузки должен буферистить получаемые данные в ожидании того, что клиентское приложение будет размещать буферы приема в подключении. После того как клиентское приложение отправляет буферы получения, целевой объект разгрузки копирует буферированные данные получения в размещенные буферы и завершает отправленные буферы путем вызоваФункция NdisTcpOffloadReceiveComplete. Дополнительные сведения см. в разделе Алгоритм доставки. Стек узла установит для переменной, заданной параметром BytesConsumed , значение 0.
Если стек узлов возвращает NDIS_STATUS_OFFLOAD_DATA_PARTIALLY_ACCEPTED, указывая, что клиентское приложение использовало подмножество получаемых данных, целевой объект разгрузки возобновляет владение указанными структурами NET_BUFFER_LIST при возврате функции NdisTcpOffloadReceiveHandler . Стек узла задаст переменной, заданной параметром BytesConsumed , ненулевое значение, указывающее объем данных в байтах, использованных клиентским приложением. Целевой объект разгрузки должен буферистить оставшиеся данные получения в ожидании того, что клиентское приложение разместит буферы получения в подключении.

Обратите внимание, что целевой объект разгрузки никогда не предоставляет значение Состояния NDIS_STATUS_RESOURCES при вызове функции NdisTcpOffloadReceiveHandler .

В члене RcvIndicationSize структуры TCP_OFFLOAD_STATE_CACHED стек узла может указать оптимальное количество байтов данных, которые целевой объект разгрузки должен предоставить в одном вызове функции NdisTcpOffloadReceiveHandler . Дополнительные сведения см. в разделе Использование указанного размера указания получения.

Требования

Требование	Значение
Целевая платформа	Универсальное
Верхняя часть	ndischimney.h (включая Ndischimney.h)
IRQL	DISPATCH_LEVEL