Procedure consigliate (piattaforma di filtro Di Windows)

L'elenco seguente contiene le procedure consigliate per lo sviluppo di applicazioni tramite l'API Windows Filtering Platform (WFP).

• 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 quindi può verificarsi un timeout.

• Usare transazioni esplicite per combinare operazioni di aggiunta o eliminazione correlate in una singola transazione.

  Ciò è 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 qualsiasi delle funzioni, le stringhe indirette vengono risolte nella risorsa stringa specificata usando le impostazioni locali del chiamante.

• Associare tutti gli oggetti a un provider.

  Quando più provider sono installati nel sistema, ciò rende più semplice per gli strumenti di diagnostica determinare chi ha aggiunto cosa.

• Aggiungere filtri al proprio sottostrato.

  Quando viene raggiunto un filtro di terminazione in un sottostrato, non vengono valutati altri filtri in tale sottostrato. Pertanto, se si aggiungono i filtri allo stesso sottostrato di un altro provider, è possibile impedire che i filtri dell'altro vengano richiamati, causando risultati imprevisti.

• Usare Ale (Application Layer Enforcement) anziché il filtro orientato ai pacchetti.

  Il filtro a livello di pacchetto è lento.

• Filtrare gli errori ICMP e gli eventi RST prima che vengano generati.

  Questo è più efficiente per filtrare questi eventi dopo la generazione.

• Eseguire l'ispezione dei pacchetti a livello di dati stream/datagram anziché a livello di trasporto.

  Questo vale per lo sviluppo di callout. Per altre informazioni, vedere Considerazioni sulla programmazione dei driver callout in 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, è possibile creare filtri 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 comportare prestazioni più lente per il motore di filtro WFP da classificare. È necessario eseguire una valutazione per determinare se l'uso di tali filtri provoca un effetto negativo sulle prestazioni complessive della soluzione.