W_TCP_OFFLOAD_RECEIVE_HANDLER funzione di callback (ndischimney.h)

Articolo
02/26/2024

[La funzionalità di offload del camino TCP è deprecata e non deve essere usata.]

NDIS chiama la funzione MiniportTcpOffloadReceive per pubblicare le richieste di ricezione (buffer di ricezione) su una connessione TCP offloaded.

Sintassi

W_TCP_OFFLOAD_RECEIVE_HANDLER WTcpOffloadReceiveHandler;

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

Parametri

[in] MiniportAdapterContext

Handle in un'area di contesto allocata di destinazione offload in cui la destinazione di offload gestisce le informazioni sullo stato relative a questa istanza dell'adattatore. Il driver miniport ha fornito questo handle a NDIS quando viene chiamato NdisMSetMiniportAttributes da Funzione MiniportInitializeEx .

[in] MiniportOffloadContext

Puntatore a una posizione di memoria contenente un valore PVOID. Questo valore PVOID fa riferimento al contesto di offload miniport che contiene l'oggetto stato per la connessione TCP in cui vengono inviate le richieste di ricezione. La destinazione di offload ha fornito questo valore PVOID quando ha scaricato l'oggetto stato della connessione TCP.

[in] NetBufferList

Puntatore a una struttura NET_BUFFER_LIST . Questa struttura può essere una struttura autonoma o la prima struttura in un elenco collegato di strutture NET_BUFFER_LIST. Ogni struttura NET_BUFFER_LIST nell'elenco descrive una struttura NET_BUFFER . La struttura NET_BUFFER esegue il mapping a una catena di elenchi di descrittori di memoria (MDLs). Le NET_BUFFER_LIST e le strutture associate sono bloccate in modo che rimangano residenti nella memoria fisica. Tuttavia, non vengono mappati alla memoria di sistema.

Valore restituito

NDIS_STATUS_PENDING è l'unico valore restituito consentito. Una destinazione di offload viene sempre completata (restituisce) le richieste di ricezione inviate in modo asincrono chiamando NdisTcpOffloadReceiveComplete.

Commenti

Un'applicazione client può pubblicare le richieste di ricezione su una connessione TCP offloaded. La destinazione di offload usa queste richieste per trasferire i dati ricevuti nella connessione all'applicazione client. Se le richieste di ricezione vengono registrate in una connessione, la destinazione di offload deve sempre usarle per trasferire i dati ricevuti nella connessione. Per altre informazioni, vedere Algoritmo di recapito.

La destinazione di offload accoda le strutture di NET_BUFFER_LIST registrate in primo luogo in ordine FIFO (First Out). La destinazione di offload usa il membro MiniportReserved di ogni struttura NET_BUFFER_LIST per accodare la struttura.

A ogni struttura NET_BUFFER_LIST passata alla funzione MiniportTcpOffloadReceive è associata una sola struttura NET_BUFFER.

La destinazione di offload deve inserire i dati nelle richieste di ricezione inviate nell'ordine FIFO. Ovvero, i dati ricevuti per primi devono essere inseriti nella prima richiesta di ricezione inviata e così via.

Lo stack host serializza le chiamate alla funzione MiniportTcpOffloadReceive in base alla connessione. Lo stack host non chiamerà la funzione MiniportTcpOffloadReceive su una connessione mentre è in corso una chiamata alla funzione MiniportTcpOffloadReceive su tale connessione. In questo modo si garantisce che le richieste di ricezione vengano sempre inviate nell'ordine corretto per la funzione MiniportTcpOffloadReceive di una destinazione offload.

Si noti, tuttavia, che lo stack host può chiamare la funzione MiniportTcpOffloadReceive su una connessione prima che la destinazione di offload abbia completato una o più chiamate precedenti alla funzione MiniportTcpOffloadReceive nella stessa connessione. Si noti anche che lo stack host può chiamare la funzione MiniportTcpOffloadReceive di una destinazione offload su una connessione mentre una o più chiamate alla funzione MiniportTcpOffloadReceive sono in corso su un'altra connessione.

Una richiesta di ricezione inviata può essere facoltativamente in una delle due modalità seguenti:

Modalità push
Modalità non di silenzio

Si noti che una destinazione di offload deve supportare sia la modalità push che la modalità Nonpush. .

Per determinare la modalità in cui si trova un buffer, una destinazione di offload chiama la macro NET_BUFFER_LIST_INFO per ottenere il valore di TcpReceiveNoPush. Se il valore è TRUE, la richiesta di ricezione è in modalità non interattiva.

Se la richiesta di ricezione è in modalità push, la destinazione di offload recupera il valore di TcpReceiveBytesTransferred chiamando la macro NET_BUFFER_LIST_INFO. Se questo valore è diverso da zero, la destinazione di offload avvia immediatamente il timer push per la connessione. Se questo valore è zero, la destinazione di offload avvia il timer push per la connessione non appena la destinazione di offload inserisce il primo byte di dati di ricezione nella richiesta di ricezione. La destinazione di offload completa sempre le richieste di ricezione compilate immediatamente. La destinazione di offload completa una richiesta di ricezione parzialmente compilata che è in modalità push se si verifica una delle condizioni seguenti:

Il timer di push scade.
La destinazione di offload riceve un segmento TCP sulla connessione con il bit PSH impostato.

Se la richiesta di ricezione è in modalità non interattiva, la destinazione di offload non avvia un timer push. La destinazione di offload completa la richiesta di ricezione solo quando viene compilata la richiesta di ricezione. La destinazione di offload ignora il bit PSH nei segmenti TCP ricevuti sulla connessione.

Se i dati vengono ricevuti in una connessione offloaded durante l'esecuzione del timer push, la destinazione di offload deve riavviare il timer push per tale connessione.