Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
L'elenco seguente contiene le procedure consigliate per lo sviluppo di applicazioni tramite l'API WFP (Windows Filtering Platform).
Usare sessioni dinamiche.
Molte applicazioni aggiungono oggetti criteri di filtro all'avvio e quindi eliminano questi oggetti all'arresto. Usando una sessione dinamica, si garantisce che questi oggetti vengano eliminati anche se l'applicazione si arresta in modo anomalo. Inoltre, la semplice chiusura dell'handle del motore all'arresto è più efficiente rispetto all'esecuzione di singole chiamate per eliminare ogni oggetto.
Gestire i timeout delle transazioni normalmente o impostare la sessione txnWaitTimeoutInMSec su infinito per evitare timeout.
Anche se non si usano transazioni esplicite, la maggior parte delle chiamate viene comunque eseguita in una transazione implicita e pertanto può verificarsi un timeout.
Usare transazioni esplicite per combinare operazioni di aggiunta o eliminazione correlate in una singola transazione.
Questo è più efficiente e semplifica la pulizia dei risultati parziali nei percorsi di errore.
Usare stringhe conformi a MUI.
Tutte le stringhe localizzabili vengono archiviate in una struttura di dati comune: FWPM_DISPLAY_DATA0. Le stringhe all'interno di questa struttura possono essere stringhe indirette del tipo supportato da SHLoadIndirectString. Prima che una struttura FWPM_DISPLAY_DATA0 venga restituita da una delle funzioni, le stringhe indirette sono risolte nella risorsa di stringa specificata utilizzando le impostazioni locali del chiamante.
Associare tutti gli oggetti a un provider.
Quando più provider sono installati nel sistema, questo rende più semplice per gli strumenti di diagnostica determinare chi ha aggiunto cosa.
Aggiungi filtri al tuo sottolivello.
Una volta raggiunto un filtro di terminazione in un sottostrato, non vengono valutati altri filtri in tale sottostrato. Pertanto, se si aggiungono i filtri allo stesso sublayer di un altro provider, è possibile impedire che i filtri dell'altro vengano richiamati, generando risultati imprevisti.
Usare Application Layer Enforcement (ALE) anziché applicare filtri orientati ai pacchetti.
Il filtro a livello di pacchetto è lento.
Filtra gli errori ICMP e gli eventi RST prima che vengano generati.
Questo è più efficiente che filtrare questi eventi dopo che sono stati generati.
Eseguire l'ispezione dei pacchetti a livello di dati stream/datagram anziché a livello di trasporto.
Questo vale per lo sviluppo di elementi di richiamo. Per ulteriori informazioni, consultare Callout - Considerazioni sulla programmazione dei driver nel Windows Driver Kit (WDK).
Prendere in considerazione le implicazioni per le prestazioni quando si usano filtri complessi.
A partire da Windows 7 e Windows Server 2008 R2, i filtri possono essere creati con più condizioni che usano la stessa chiave di campo. In questo modo è possibile creare criteri complessi con un minor numero di filtri. Tuttavia, tali filtri complessi potrebbero rallentare le prestazioni del motore di filtro WFP nella classificazione. È necessario eseguire una valutazione per determinare se l'uso di tali filtri causa un effetto negativo sulle prestazioni complessive della soluzione.