TDI Transports and Their Clients - I

TDI Transports and Their Clients

本章描述了TDI傳輸驅動(TDI transport drivers)以及TDI 核心模式客戶(TDI kernel mode clients)之間的關係。例如一個高階層的網路介面模擬器，重定向器(redirectors)或是一個服務(servers)使用系統所定義的TDI介面來與傳輸協議層打交道。這裡探討相關的資訊包含如下:

• PnP-aware TDI transports如何使用裝置物件(device object)來表示它的傳輸層與底層NIC間的綁定。
• PnP-aware TDI transports如何動態註冊可用的網路地址，讓TDI客戶端通過使用這些綁定。
• TDI如何使用檔案物件(file objects)來表示網路實體。
• 傳輸驅動派遣TDI要求的常式(routines)。
• 客戶(TDI Client)與傳輸(TDI Transport)間的互動。
• 區分TDI請求與TDI事件。

Transport Driver Interface

下圖展示TDI客戶與傳輸驅動之間的關係。

如該圖所示，在所有傳輸協議堆疊的上層邊界上定義了一個核心模式的網路接口，稱作傳輸驅動接口(TDI)。對於在TDI接口之上的核心模式網路客戶，每一個堆疊中最高層級的協議驅動都支援客戶端TDI接口。該接口包含如下:

• 每一個TDI傳輸驅動會導出(export)一組標準的核心模式中間層驅動派遣例程(Dispatch routines)。上層的客戶端可以提交I/O請求(IRPs)來調用支援的例程，例如Zw..File routines或是 IoCallDriver。
• 每一個TDI客戶端可以向下層的傳輸驅動註冊自己的ClientEventXxx 回呼例程，每當指定的網路事件發生，下層可以調用回呼例程並且通知客戶端接收事件發生。
• 每一個TDI客戶端可以向下層的傳輸驅動註冊自己的ClientPnPXxx 回呼例程，下層可以調用此回呼例程並且通知客戶端接收一個來自於PnP的變動發生，例如動態綁定(binding)，網路位址，以及電源狀態等變動。
• 傳輸與客戶端可以調用系統所支援的TdiXxx 函式來與對方溝通。
• 客戶端如果要向下層的傳輸協議提交一個I/O請求，可以使用一組系統所支援的TdiBuildXxx 巨集以及函式來建立此I/O請求。

要求所有的傳輸驅動程式公開一個單一通用介面(TDI)簡化了傳輸驅動程式的開發工作，這讓所有的傳輸驅動只需要支援單一定義的接口。這也簡化了客戶端的開發工作，TDI最大限度地減少客戶端在指定傳輸所必須撰寫的編碼量。

在Windows2000以及之後作業系統版本包含了多個常用的網路接口模組，例如Windows Socket以及NetBIOS。每一個接口都公開一組原始的函式，讓來自於使用者模式的程式可以用於調用訪問。當被調用時，接口模組會對原始函式，關聯的參數，以及程序規則映射一個或多個底層TDI傳輸驅動的調用。

下列包含了TDI的主要特徵:

High Level of Granularity 

TDI容納所有流行的網路接口，因為它在本質上是相對粒度，具有可以混合和匹配的特性，以適應從現有的網絡接口功能映射至幾個小的TDI定義請求。

Asynchronous Operation

大多數核心模式的TDI操作為異步的，使用客戶端提供的回呼例程來指示異步網路事件的發生，以及通知客戶端提交的異步IRPs已經完成。

32-bit Addressing and Values

如同Windows2000以及之後版本的核心模組一樣，TDI傳輸以及它的客戶端為32-bit碼。TDI定義的結構以及參數使用32-bit的指標以及值。

Flexible Addressing Scheme

TDI並不強制要求任何特定的位址格式，如舊式作業系統定義的16字符的NetBIOS名稱。相反，它採用了由許多位址格式可以識別和使用的可擴展的機制。

Extensible Communication

TDI定義了TDI_ACTION IOCTL要求，任何TDI傳輸可以用於支援一個傳輸操作集合。這允許客戶端提交一個TDI裡沒有具體定義的傳輸特殊要求給下層傳輸驅動。

Event Notification

TDI定義一個計劃，傳輸(transports)可以通知客戶端它有興趣的網路事件已經發生，而不需要客戶端明確的提交一個I/O請求。

Plug and Play Event Notifications

TDI定義一個計畫，在Windows2000以後傳輸端可以通知它的客戶端某些PnP事件，例如底層NIC的可用性和本地網路位址連接的創建/刪除。

System Power-State Change Notifications

TDI定義一個計畫，傳輸在Windows2000之後可以通知它的客戶系統電源狀態的改變，從而給客戶端一個機會保持通電的活動連接。

下列的特徵可以由TDI傳輸驅動程式決定額外的支援:

Data Transfer Modes

TDI支援發送與接收離散數據訊息((message mode)或是一個位元流(byte-stream mode)。支援其一或是全部支援取決於傳輸驅動的寫法或是協議的性質。

Internal Buffering 
TDI傳輸可以在內部作客戶端的收發緩衝。傳輸內部緩衝允許TDI客戶設定以及詢問驅動內部緩衝的大小，要求一個非同步發送操作，接收可用緩衝區空間的通知，以及在客戶端接收數據之前先監看緩衝區內的數據。

Management Options 
所有的傳輸(transport) 對於他們自己的特徵，限制，以及運行的統計數據維護一些TDI定義的狀態。這允許每一個客戶端動態的詢問或是在一些狀況下去設定傳輸提供者靜態資訊，統計數據以及參數設定。前面有提到的TDI_ACTION IOCTL就是這樣的例子。允許TDI傳輸驅動實作獨一無二的網管特徵，然後讓它的客戶端藉著action要求來使用它。

Quality of Service (QoS) 
TDI傳輸可以在建立網路連結上提供QoS協商。另外，一個驅動可以在無連接的數據報傳輸上支援QoS。要支援其一，TDI定義的建立連結以及數據報發送請求包含參數Options 以及OptionsLength，這允許一個TDI客戶端包含特定傳輸，可變長度計算字符串，指定的QoS選項。事實上，Options 和OptionsLength參數可用於在驅動程序的作者，而不僅僅是QoS規範。

Expedited Delivery 
當發送訊息，客戶端可以標記特定的訊息為急件(expedited)。在發送端，下層傳輸這些訊息在非急件(nonexpedited)訊息之前。而在接收端，急件訊息被指示到客戶端在非急件消息之前。

Chained Receive Indications 
如果下層的NDIS微阜驅動程式(NDIS miniport)支援多封包接收指示，則一個TDI傳輸可以賦予它的客戶端在單一調用中直接讀取一個完整的TSDU，並且客戶可以保留包含TSDU緩衝區的控制直到它消耗完只示的數據。這項特徵透過減少調用接收指示來增進傳輸與客戶端的效能