基于驅動程序的協議棧設計，相比于傳統的基于任務的協議棧設計來說有兩點好處：(1)效率更高；(2)對于有多個協議棧的系統來說，有更大的兼容性。
1 基于任務的方式
　　在我們比較兩種設計方式的技術細節之前，我們必須了解它們。傳統的設計方式包括將協議棧置于實時操作系統或內核之上，但是大多數實時操作系統不提供網絡互連的框架。所以，協議棧的設計者們不得不利用實時操作系統提供的機制——Task。圖1說明了如何利用任務來實現一個三層間通信的協議。每一層被作為一個單獨的任務，外加任務間通信機制負責傳送數據和控制包上下通過協議棧，程序設計者負責定義層與層之間的接口和一個應用程序接口(API)，以利于應用程序員傳送和接收數據。

　　在這里存在幾個效率不高的來源：首先，正如圖1中點線所說明的，當包在應用程序、上層的通信協議，以及網絡接口的設備驅動程序之間交換時，下層的操作系統正忙于上下文切換，每一次實時操作系統掛起其中一個任務，恢復執行另一個任務，時間都浪費在存取任務上下文中，考慮到每一個包無論是發還是收，都要通過協議棧的每一層，上下文切換的確造成了巨大的浪費。另外，當數據和控制包在應用程序任務和網絡接口之間流動時，包含此類信息的緩沖區必然重復在任務間通信隊列加入或刪除。然而，這個系統開銷是很大的，這本身是由于系統在隊列操作時必然包括需與中斷和上下文切換隔離的臨界區。因此，不僅時間浪費于隊列操作，而且整個系統對一些重要的事件例如中斷的響應變得延遲。
2 基于驅動程序的方法
　　另外一種選擇是將協議棧各層置于實時操作系統之中，圖2說明了基于此種方案，同樣的三層間通信協議是如何實施的。兩者之間的顯著區別在于：各個協議層是作為驅動程序模塊，而不是任務來實現的。

　　另外一個改變在于：協議棧之上還有一個網絡服務模塊。加入這個模塊的目的在于將與協議無關的網絡特性抽象化。也就是說，它將應用程序設計者用來在協議棧間收發數據的應用程序接口(API)標準化，例如：你的嵌入式系統可能需要同時支持基于調制解調器接口的PPP連到一臺遠程計算機和一個紅外接口用來與本地計算機通信。然而程序設計者不必為兩個事件各自編程，它只需用網絡服務模塊提供API與其它計算機進行通信，唯一的區別在于通過哪個網絡接口而已。
　　基于驅動程序方式的一個顯著優點就在于上下文切換的次數僅僅是基于控制臺應用程序的函數，并不基于協議層的數量。這樣一來就可以減少實時操作系統保存和恢復任務上下文的次數，因而空出時間作更有意義的事，例如執行應用程序代碼。
　　另一個好處在于，數據和控制信息更簡單的在層與層之間傳輸，因為所有的協議層都處于同一個上下文中，所以相關的數據結構自動地為上下層所接受，結果你不必把他們在任務間隊列中傳送，由此產生的是，同時也避免了那些臨界區系統由此可改進中斷和優先級任務的響應時間。
3 緩沖區拷貝
　　緩沖區拷貝效率不高的第一個潛在因素在于：當數據在層與層之間傳輸時，數據緩沖區的分配、拷貝和釋放，這與協議棧的結構無關，僅與緩沖區本身的結構有關。
　　一般來說，有兩種常用的方式用于協議棧層與層之間傳送數據，如圖3所示。然而，這兩種方式均有缺陷，我們假設，應用層有一些數據需要傳送，通常我們把它稱作消息，消息需被送至協議棧的最底層，因為在緩沖區中沒有多余的空間來存放頭尾信息，而協議層必須給數據本身加上頭尾信息，協議層或分配一個足夠大的緩沖區得以容納消息本身和頭尾信息，或分配兩個小緩沖區，一個用于頭信息，一個用于尾信息，然后用指針將三個緩沖區鏈接起來。

　　眾所周知，每一層加入自己的頭尾信息源于上一層傳來的信息。因此，一個包在自上而下通過網絡時，必須重復這一個過程許多次，時間被消耗于內存的分配之中(而自下而上則好得多，因為下層的頭尾信息可以被上層忽略)。這種拷貝方式同時伴隨著越來越大的消息，釋放老緩沖區。鏈接方式雖然不涉及多余的拷貝，但是卻將傳輸包的設備驅動程序代碼復雜化。

　　另一種替代的方式與基于設備驅動程序的方式相當吻合，如圖4所示。每次當協議棧創建或改變時，網絡服務模塊執行一個查詢以確定整個協議棧的頭、尾信息和最大傳輸單元要求，這樣一來當應用程序向協議棧發消息時，網絡服務模塊相應地分配一些足夠大容納整個協議棧頭尾信息的緩沖區，每一層僅僅將頭尾信息填充至這些緩沖區，而不需內存分配或拷貝，這一機制對于性能有顯著的改善。
　　重傳緩沖區另一個效率不高的原因在于，協議層提供確認與重傳機制，一個可靠的協議層的實現通常包括為每個包分配一個重傳緩沖區，將包的內容拷貝至重傳緩沖區中。如果遠程系統的同一層確認了正確接收，重傳緩沖區將被釋放，然而，如果一個“NACK”發生，協議層重傳緩沖區的內容，同時再分配一個重傳緩沖區，拷貝內容至重傳緩沖區。
　　如果已經發出的包可以被協議層標記為“Unmarked”或“Reserved”的話，上述機制就可被取消，這種情況僅保存一個指針而不拷貝。當設備驅動程序完成傳送包并試圖釋放緩沖區，緩沖區系統確認此緩沖區保留，并不釋放包，僅僅將它標記為“已傳輸”，當相應的協議層收到確認(ACK)之后，就把包去掉標識，并且釋放緩沖區，通過把這一特性固化至網絡服務模塊中，整個協議棧的效率將大大提高。
4 細節
　　任何合理的基于驅動程序的協議棧都會包含相似的數據結構、數據和控制原語及模塊函數。下面介紹一下細節數據結構，以下是一些可能用到的數據結構。
　　(1) 設備入口提供實時操作系統和某一特殊的協議模塊的管道；
　　(2) 驅動程序靜態變量對于每一協議層僅分配一次，不管協議層下的網絡接口有多少，它是協議層的全局存儲區域；
　　(3) 邏輯單位靜態變量僅基于接口分配，所以如果你有一個設備驅動程序控制兩個接口，就應有兩個邏輯單位靜態變量，但是僅有一個驅動程序變量和一個設備條目數據結構；
　　(4) 路徑變量基于應用程序對協議的調用，僅分配一次。
　　基于上述四種定義，協議中的各種數據應被定義為最合適的類型，被選定的數據結構應當基于這個變量如何被使用：是被協議狀態機所使用，還是接口或是應用程序，例如，一個特定的網絡接口芯片在內存中的基址就應定義為邏輯單位靜態變量。
5 函數
　　如果你正開發不止一個協議棧，編寫一系列通用的函數會有幫助，表1、表2描述了一些基于驅動程序的協議?？蚣艿臄祿涂刂苽鬏斣Z及參數。

?

參考文獻
1 Curt Schwaderer.A Driver－Based Approach to Protocol Stack Design. Embedded Systems Programming,1999;12 (9)
2 Bill Gatliff.An introduction to Protocol Stack Design.IEEE Software Design,1998;4