Windows 篩選平台) (最佳做法
下列清單包含使用 Windows 篩選平台 () API 開發應用程式的最佳做法。
使用動態會話。
許多應用程式會在啟動時新增篩選原則物件,然後在停止時刪除這些物件。 藉由使用動態會話,您保證即使應用程式當機,也會刪除這些物件。 此外,只要在停止關閉引擎控制碼會比進行個別呼叫來刪除每個物件更有效率。
請正常處理交易逾時,或將會話 txnWaitTimeoutInMSec 設定為無限,以防止逾時。
即使您未使用明確交易,大部分的呼叫仍會在隱含交易下執行,因此可能會逾時。
使用明確交易,將相關的新增或刪除作業合併成單一交易。
這更有效率,可讓您輕鬆地清除部分結果的錯誤路徑。
使用符合 MUI 規範的字串。
所有可當地語系化的字串都會儲存在通用資料結構中: FWPM_DISPLAY_DATA0。 此結構中的字串可以是 SHLoadIndirectString所支援類型的間接字串。 在任一函式傳回 FWPM_DISPLAY_DATA0 結構之前,間接字串會使用呼叫端的地區設定解析為指定的字串資源。
將所有物件與提供者產生關聯。
在系統上安裝多個提供者時,這可讓您更輕鬆地讓診斷工具判斷新增內容的人員。
將篩選新增至您自己的子圖層。
叫用子圖層中的終止篩選之後,就不會再評估該子圖層中的篩選。 因此,如果您將篩選新增至與另一個提供者相同的子圖層,您可能會防止彼此叫用篩選,因而產生非預期的結果。
使用應用層強制執行 (ALE) ,而不是封包導向篩選。
封包層的篩選速度很慢。
在產生 ICMP 錯誤和 RST 事件之前,先篩選 ICMP 錯誤和 RST 事件。
在產生這些事件之後,這會更有效率地篩選這些事件。
在 Stream/Datagram 資料層執行封包檢查,而不是在傳輸層執行。
這適用于開發圖說文字。 如需詳細資訊,請參閱 Windows 驅動程式套件中的 圖說文字驅動程式程式設計考慮 (WDK) 。
使用複雜篩選準則時,請考慮效能影響。
從 Windows 7 和 Windows Server 2008 R2 開始,可以使用多個條件來建立篩選準則,以使用相同的欄位索引鍵。 這可讓使用較少的篩選準則來建立複雜的原則。 不過,這類複雜的篩選可能會產生較慢的效能,讓一般篩選引擎分類。 應該進行評估,以判斷使用這類篩選是否會對解決方案的整體效能造成負面影響。