![中間層[網路協定概念]](/img/9/498/nBnauM3X2QTNwYDNzgzN0MjN3QTM4QzM5YjNzQTNwAzMwIzL4czL3czLt92YucmbvRWdo5Cd0FmL0E2LvoDc0RHa.jpg "中間層[網路協定概念]")
信息簡介
典型情況下Web伺服器位於中間層(MiddleTier)，業務對象在此實例化。中間層是生成並操作接收信息的業務規則和函式的集合。它們通過業務規則（可以頻繁更改）完成該任務，並由此被封裝到在物理上與套用程式程式邏輯本身相獨立的組件中。
網路結構
中間層通過這樣的結構設計，使得套用邏輯被所有用戶共享，這是兩層結構套用軟體與三層套用軟體之間最大的區別。三層結構將表示部分和業務邏輯部分按照客戶層和套用服務層相分離，客戶端和套用服務層、套用服務層和資料庫服務層之間的通訊、異構平台之間的數據交換等都可以通過中間件或者相關程式來實現。當資料庫或者套用服務層的業務邏輯改變時，客戶端並不需要改變，反之亦然，大大提高了系統模組的復用性，縮短開發周期，降低維護費用。以Java Applet為客戶端， 以Java Servlet為中間層的三層網路結構，在目前的實時網路信息平台得到了廣泛的套用。
註冊表常識
1、設備資料庫所在的註冊表健值為：
HKLM\SYSTEM\CurrentControlSet\Enum\
ENUM子項中是一個設備資料庫，在資料庫存放計算機中所有安裝的，並且被系統認識到的設備。
所有的用戶（包括管理員）都不能更改ENUM項的內容。這是為了保護作業系統和安裝的設備的完整性。為了更改設備的設定，應該使用"設備管理器"。
為了在設備管理器中現實隱藏的，非即插即用的，以及沒有連線到計算機上的所有設備，你應該首先在命令解釋器中敲入命令set DEVMGR_SHOW_NONPRESENT_DEVICES=1，然後啟動設備管理器，就可以在設備管理器中刪除和重新配置這些設備了。
中間層Class項下存放硬體設備類的配置信息。在Class項下的每個子項都代表一個設備類，子項的名稱使用"唯一全局標識符（GUIS）"，這些標識符存放該設備類的配置信息。在每個類標識符下，還會有以4位數命名的子項，他們代表該設備類里的具體設備，其他的配置數據只套用於該具體設備。
如網卡的設備類是{4D36E972-E325-11CE-BFC1-08002BE10318}，並假定我們網卡對應的4為數命名子項名為0005。
其中HKLM\SYSTEM\CurrentControlSet\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0005\Linkage\ 中：
Export：代表該設備在設備名字空間輸出的設備名字。
RootDevice：代表當前設備的GUID。中間層驅動這裡有兩個GUID，第一個是自己的GUID，第二個是該中間層驅動綁定的下層MINIPORT的GUID。
UpperBind：代表上層綁定它的NDIS協定驅動或NDIS中間層驅動。當某個協定驅動綁定該MINIPORT設備時，則這個協定驅動的名字必須出現在UpperBind健值的字元串中，否則不能進行綁定。也就是說，UpperBind健值的字元串決定了那個協定驅動（當然也包括中間層驅動註冊的協定）和當前的MINIPORT設備綁定，即，它決定了NDIS的上下層綁定關係。
註：一般添加中間層驅動後，中間層驅動只插入到真是網卡和相應協定中間，不會插入到虛擬網卡（如安裝虛擬機後虛擬出來的網卡設備）和相應協定中間。
3、驅動程式所在的註冊表健值為：
HKLM\SYSTEM\CurrentControlSet\Services
ENUM子項
通常如果某個服務下存在ENUM子項，表明該服務是用來控制某個設備或者設備互動的，它的下面存放該設備的實例。用戶不要去試圖修改該子項的內容，因為每次系統啟動時，都會重寫該子項的內容。
LINKAGE子項
值項Bind
存放該協定所在綁定棧的最低層小連線埠設備實例（即MINIPORT）。
值項Export
存放該服務必須訪問的對象，該對象必須已經安裝在系統中，並且該服務能夠使用。
值項Route
指定子項Linkage從那裡獲取綁定數據。
Parameters\ Adapters\子項
中間層驅動
在我們的函式NDIS_PROTOCOL_CHARACTERISTICS-> BindAdapterHandler（）中，會調用一系列函式（如NdisOpenProtocolConfiguration、NdisReadConfiguration）來訪問註冊表，其實都是訪問Parameters\Adapters\{102454C2-9DB3-42A1-B4CF-6A8B67A516C0}子項。
注意，函式NDIS_PROTOCOL_CHARACTERISTICS-> BindAdapterHandler（）的倒數第二個參數是SystemSpecific1，如果我們安裝的是XPASSTHRU，則其具體指的是如下字元串：
xfilter\Parameters\Adapters\{102454C2-9DB3-42A1-B4CF-6A8B67A516C0}
其中xfilter 是XPASSTHRU的，而{102454C2-9DB3-42A1-B4CF-6A8B67A516C0}在不同的系統中不同。
函式NdisOpenProtocolConfiguration（）其實只是構造一個查詢註冊表的RTL_QUERY
_REGISTRY_TABLE結構（該結構在利用函式RtlQueryRegistryValues（）查詢註冊表是使用）。並將這個結構封裝到NDIS_WRAPPER_CONFIGURATION_HANDLE結構中，然後作為NdisOpenProtocolConfiguration（）的第二個參數返回。
其實NdisOpenProtocolConfiguration（）構造的RTL_QUERY_REGISTRY_TABLE結構的含義也就是查詢HKLM\SYSTEM\CurrentControlSet\Services\ xfilter\Parameters\Adapters\{102454C2-9DB3-42A1-B4CF-6A8B67A516C0}\下的健值（xfilter 會隨著安裝不同的
中間層函式NdisReadConfiguration（）有兩個作用，它首先修改在函式NdisOpenProtocolConf
iguration（）構造的RTL_QUERY_REGISTRY_TABLE結構。也就是在查詢HKLM\SYSTEM
\CurrentControlSet\Services\ xfilter\Parameters\Adapters\{102454C2-9DB3-42A1-B4CF-6A8B6
7A516C0}\的基礎上加上了一個健，將其變成HKLM\SYSTEM\CurrentControlSet\Services\ xfilter\Parameters\Adapters\{102454C2-9DB3-42A1-B4CF-6A8B67A516C0}\UpperBindings。然後函式NdisReadConfiguration（）會調用函式RtlQueryRegistryValues（）查詢新構造的這個註冊表，並將結果存儲在調用函式NdisReadConfiguration()時的第二個參數中。在我的系統中，RtlQueryRegistryValues（）讀出的這個新構造的這個註冊表的健值是：\Device\ {5BF5A311-13E4-4746-8865-339DDD6C73AF}（後面我們稱為RESULT1），它其實是我們註冊的中間層驅動（XPASSTHRU）的設備輸出（其構造是\Device＋\GUID）。
其實我們讀出的這箇中間層驅動（XPASSTHRU）的設備（即我們剛才讀出的那個健值RESULT1）只在後面的函式NdisIMInitializeDeviceInstanceEx（）中才用得著，並且RESULT1是作為函式NdisIMInitializeDeviceInstanceEx（）的第二個參BindAdapterHandler（）我們一旦調用了函式NdisOpenAdapter（）綁定了一個下層的MINIPORT，為什麼還要調用函式NdisIMInitializeDeviceInstanceEx（）初始化我們中間層驅動自己的MINIPORT（因為函式NdisIMInitializeDeviceInstanceEx（）的參數是RESULT1，而RESULT1代表我們中間層驅動的MINIPORT）。為了解釋這個原因，我們先做如下假設。
當PROT-TCPIP需要傳送數據時，會調用函式NdisSend()，其實它會調用MINIPORT-IM中的傳送數據函式，但是MINIPORT-IM和MINIPORT-NIC沒聯繫，按照常規是不能傳送數據到MINIPORT-NIC的。但是我們可以看到PROT-IM是可以和MINIPORT-NIC互相傳送數據的，所以我們必須將MINIPORT-IM和PROT-IM聯繫起來。
另外當MINIPORT-NIC需要將數據提交給PROT-TCPIP時，只能首先將數據提交給PROT-IM，PROT-IM也只能通過MINIPORT-IM才能和PROT-TCPIP聯繫起來。
所以必須將PROT-IM和MINIPORT-IM聯繫起來。有人說這兩個東西都是我們中間層驅動註冊得，難道還聯繫不起來嗎？不錯，但是不管怎樣你都得通過你得代碼才能將他們聯繫起來呀！下面我們就介紹聯繫得方法。
我們以XPASSTHRU為例，在其函式ProtocolBindAdapter（）中，先分配了一個ADAPT結構（這個結構是自己定義的，可根據用戶的需要定義）。當調用函式ProtocolBindAdapter（）調用函式NdisOpenAdapter（）進行綁定時，是以&Adapt->BindingHandle作為函式NdisOpenAdapter（）的第三個參數的，這樣Adapt->BindingHandle就指向了NDIS_OPEN_BLOCK1（注意，調用函式NdisOpenAdapter（）時的第三個參數會返回指向綁定以後的NDIS_OPEN_BLOCK指針）。然後函式ProtocolBindAdapter（）會調用函式NdisIMInitializeDeviceInstanceEx（），該函式會進一步調用XPASSTHRU的NDIS_MINIPORT_CHARACTERISTICS->InitializeHandler（）函式。上面我們討論過，NdisIMInitializeDeviceInstanceEx（）中的第二個參數就是XPASSTHRU註冊的小連線埠驅動的設備實例（即上面的RESULT1）。在函式NdisIMInitializeDeviceInstanceEx（）中會根據設備名稱（RESULT1），找到對應的MINIPORT結構，並將其指針作為參數傳遞給NDIS_MINIPORT_CHARACTERISTICS->InitializeHandler（）函式（以後簡稱InitializeHandler（）函式）。在InitializeHandler（）函式中，會進一步將MINIPORT結構指針賦值給ADAPT->MiniportHandle（ADAPT就是上面在函式ProtocolBindAdapter（）中分配的那個結構）。
這樣數據結構ADAPT中就含有了兩個指針，一個指向NDIS_OPEN_BLOCK1，另一個指向MINIPORT-IM，而NDIS_OPEN_BLOCK1和PROT-IM是密切聯繫的，所以ADAPT就將PROT-IM和MINIPORT-IM緊密的聯繫起來了。
另外注意，NDIS_MINIPORT_BLOCK->DeviceContext是指向我們的ADAPT結構的，這個賦值在函式NdisIMInitializeDeviceInstanceEx（）中完成。上面談到了也是在函式NdisIMInitializeDeviceInstanceEx（）中完成了從ADAPT-> MiniportHandle到MINIPORT的綁定，所以在函式NdisIMInitializeDeviceInstanceEx（）中完成了ADAPT和MINIPORT的互相連線（即指針互相指向）。
函式InitializeHandler（）中可以利用句柄MINIPORT的句柄得到我們的ADAPT結構，具體實現這個功能的函式是NdisIMGetDeviceContext（），這個函式的參數是個NDIS_HANDLE類型，但是在該函式內部，會將這個參數轉換成NDIS_MINIPORT_BLOCK結構，並返回NDIS_MINIPORT_BLOCK->DeviceContext。
在函式NdisOpenAdapter（）中，除了上面提到的完成了由Adapt->BindingHandle到NDIS_OPEN_BLOCK1的指向外，還完成了我們沒有提到的由NDIS_OPEN_BLOCK1-> ProtocolBindingContext到ADAPT的指向，所以函式NdisOpenAdapter（）完成了ADAPT和NDIS_OPEN_BLOCK1的互相連線（即指針互相指向）。
