關於TDI的一些想法

在Windows上，基於某些應用，我們考量系統設計不會將所有的組件都設計在使用者模式上，即便在使用者模式我們有更多資源能夠比核心上使用更多且更簡單的API做到相同的功能。例如，一個虛擬裝置可能需要模擬遠端裝置的功能，而中介軟體只是負責命令的轉發，讓客戶端的軟體可以操控這個虛擬裝置如同操縱遠在300KM以外的裝置一般。那這個中介軟體可能是一個虛擬裝置的驅動程式，雙方的溝通可能透過TCP/IP網路。這裡的網路封包設計，當然可以像一般網路應用程式般，在使用層撰寫一個背景服務(微軟上稱為service，Linux應該是稱作daemon)來操作winsock的網路操作。但不得不說這樣的設計並沒有很聰明，我會這樣說是因為微軟的系統架構中，底層驅動收到的命令前，通常會透過IO manager轉換為一個IRP的封包，一般應用程式blocking的寫法，上層發出命令後會進入等待狀態，直到系統回覆這個動作完成。驅動軟體(這裡只考慮單層驅動)會收到這個命令並且決定這個IRP是否完成。考慮上面的情形，背景程式負責網路處理，所以驅動收到命令，還要將命令格式(command類型)，數據緩衝區，數據大小等資訊複製一份給上層知道，然後服務完成了網路通訊以後，在向核心通知命令完成，然後驅動在回覆給系統命令已經完成。光想到要花費那們多力氣撰寫程式還要面對後續的維護問題(上下層的同步問題)，你還會堅持這樣的想法嗎?? 所以就我自己的經驗這樣的應用還是傾向將所有的架構都設計在核心層。所以學習網路核心介面就有其必要性了。

下一章就是有關TDI的介紹，主要是翻譯官網的文件。有關TDI驅動的部分，官網會討論三個主題，1. TDI Transports and Their Clients 2. TDI Routines, Macros, and Callbacks, 3. TDI Operations。這部分要注意的是官網會在它的文件上一直提到，在Vista以後，像使用這類的NPI請用WSK(Windows Socket Kernel)來取代傳統的TDI寫法，然後想寫網路過濾驅動請使用WFP，應該是用來取代NDIS 中間層驅動。我目前的驅動在Windows7運行TDI的部分還是正常，看來微軟還是有保留TDI的運作模式，不過我自己也是有在研讀WSK的文件，畢竟如果未來想要支援IPV6的話，使用WSK實作上是相對簡單的。