一種協(xié)議棧設計和實現(xiàn)

精品文檔-下載后可編輯一種協(xié)議棧設計和實現(xiàn)

基于驅(qū)動程序的協(xié)議棧設計，相比于傳統(tǒng)的基于任務的協(xié)議棧設計來說有兩點好處：（1）效率更高；（2）對于有多個協(xié)議棧的系統(tǒng)來說，有更大的兼容性。

協(xié)議棧是指網(wǎng)絡中各層協(xié)議的總和，其形象的反映了一個網(wǎng)絡中文件傳輸?shù)倪^程：由上層協(xié)議到底層協(xié)議，再由底層協(xié)議到上層協(xié)議。使用廣泛的是英特網(wǎng)協(xié)議棧。協(xié)議棧是指網(wǎng)絡中各層協(xié)議的總和，其形象的反映了一個網(wǎng)絡中文件傳輸?shù)倪^程：由上層協(xié)議到底層協(xié)議，再由底層協(xié)議到上層協(xié)議。使用廣泛的是英特網(wǎng)協(xié)議棧，由上到下的協(xié)議分別是：應用層（HTTP,TELNET,DNS,EMAIL等），運輸層（TCP,UDP），網(wǎng)絡層（IP），鏈路層（WI-FI,以太網(wǎng)，令牌環(huán)，F(xiàn)DDI等），物理層。

1基于任務的方式

在我們比較兩種設計方式的技術(shù)細節(jié)之前，我們必須了解它們。傳統(tǒng)的設計方式包括將協(xié)議棧置于實時操作系統(tǒng)或內(nèi)核之上，但是大多數(shù)實時操作系統(tǒng)不提供網(wǎng)絡互連的框架。所以，協(xié)議棧的設計者們不得不利用實時操作系統(tǒng)提供的機制--Task.圖1說明了如何利用任務來實現(xiàn)一個三層間通信的協(xié)議。每一層被作為一個單獨的任務，外加任務間通信機制負責傳送數(shù)據(jù)和控制包上下通過協(xié)議棧，程序設計者負責定義層與層之間的接口和一個應用程序接口（API），以利于應用程序員傳送和接收數(shù)據(jù)。

在這里存在幾個效率不高的：首先，正如圖1中點線所說明的，當包在應用程序、上層的通信協(xié)議，以及網(wǎng)絡接口的設備驅(qū)動程序之間交換時，下層的操作系統(tǒng)正忙于上下文切換，每實時操作系統(tǒng)掛起其中一個任務，恢復執(zhí)行另一個任務，時間都浪費在存取任務上下文中，考慮到每一個包無論是發(fā)還是收，都要通過協(xié)議棧的每一層，上下文切換的確造成了巨大的浪費。另外，當數(shù)據(jù)和控制包在應用程序任務和網(wǎng)絡接口之間流動時，包含此類信息的緩沖區(qū)必然重復在任務間通信隊列加入或刪除。然而，這個系統(tǒng)開銷是很大的，這本身是由于系統(tǒng)在隊列操作時必然包括需與中斷和上下文切換隔離的臨界區(qū)。因此，不僅時間浪費于隊列操作，而且整個系統(tǒng)對一些重要的事件例如中斷的響應變得延遲。

2基于驅(qū)動程序的方法

英文名為"DeviceDriver",全稱為"設備驅(qū)動程序"是一種可以使計算機和設備通信的特殊程序，可以說相當于硬件的接口，操作系統(tǒng)只有通過這個接口，才能控制硬件設備的工作，假如某設備的驅(qū)動程序未能正確安裝，便不能正常工作。因此，驅(qū)動程序被譽為"硬件的靈魂"、"硬件的主宰"、和"硬件和系統(tǒng)之間的橋梁"等。

另外一種選擇是將協(xié)議棧各層置于實時操作系統(tǒng)之中，圖2說明了基于此種方案，同樣的三層間通信協(xié)議是如何實施的。兩者之間的顯著區(qū)別在于：各個協(xié)議層是作為驅(qū)動程序模塊，而不是任務來實現(xiàn)的。

另外一個改變在于：協(xié)議棧之上還有一個網(wǎng)絡服務模塊。加入這個模塊的目的在于將與協(xié)議無關的網(wǎng)絡特性抽象化。也就是說，它將應用程序設計者用來在協(xié)議棧間收發(fā)數(shù)據(jù)的應用程序接口（API）標準化，例如：你的嵌入式系統(tǒng)可能需要同時支持基于調(diào)制解調(diào)器接口的PPP連到一臺遠程計算機和一個紅外接口用來與本地計算機通信。然而程序設計者不必為兩個事件各自編程，它只需用網(wǎng)絡服務模塊提供API與其它計算機進行通信，的區(qū)別在于通過哪個網(wǎng)絡接口而已。

基于驅(qū)動程序方式的一個顯著優(yōu)點就在于上下文切換的次數(shù)僅僅是基于控制臺應用程序的函數(shù)，并不基于協(xié)議層的數(shù)量。這樣一來就可以減少實時操作系統(tǒng)保存和恢復任務上下文的次數(shù)，因而空出時間作更有意義的事，例如執(zhí)行應用程序代碼。

另一個好處在于，數(shù)據(jù)和控制信息更簡單的在層與層之間傳輸，因為所有的協(xié)議層都處于同一個上下文中，所以相關的數(shù)據(jù)結(jié)構(gòu)自動地為上下層所接受，結(jié)果你不必把他們在任務間隊列中傳送，由此產(chǎn)生的是，同時也避免了那些臨界區(qū)系統(tǒng)由此可改進中斷和優(yōu)先級任務的響應時間。

3緩沖區(qū)拷貝

緩沖區(qū)拷貝效率不高的個潛在因素在于：當數(shù)據(jù)在層與層之間傳輸時，數(shù)據(jù)緩沖區(qū)的分配、拷貝和釋放，這與協(xié)議棧的結(jié)構(gòu)無關，僅與緩沖區(qū)本身的結(jié)構(gòu)有關。

一般來說，有兩種常用的方式用于協(xié)議棧層與層之間傳送數(shù)據(jù)，如圖3所示。然而，這兩種方式均有缺陷，我們假設，應用層有一些數(shù)據(jù)需要傳送，通常我們把它稱作消息，消息需被送至協(xié)議棧的層，因為在緩沖區(qū)中沒有多余的空間來存放頭尾信息，而協(xié)議層必須給數(shù)據(jù)本身加上頭尾信息，協(xié)議層或分配一個足夠大的緩沖區(qū)得以容納消息本身和頭尾信息，或分配兩個小緩沖區(qū)，一個用于頭信息，一個用于尾信息，然后用指針將三個緩沖區(qū)鏈接起來。

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

另一種替代的方式與基于設備驅(qū)動程序的方式相當吻合，如圖4所示。每次當協(xié)議棧創(chuàng)建或改變時，網(wǎng)絡服務模塊執(zhí)行一個查詢以確定整個協(xié)議棧的頭、尾信息和傳輸單元要求，這樣一來當應用程序向協(xié)議棧發(fā)消息時，網(wǎng)絡服務模塊相應地分配一些足夠大容納整個協(xié)議棧頭尾信息的緩沖區(qū)，每一層僅僅將頭尾信息填充至這些緩沖區(qū)，而不需內(nèi)存分配或拷貝，這一機制對于性能有顯著的改善。

重傳緩沖區(qū)另一個效率不高的原因在于，協(xié)議層提供確認與重傳機制，一個可靠的協(xié)議層的實現(xiàn)通常包括為每個包分配一個重傳緩沖區(qū)，將包的內(nèi)容拷貝至重傳緩沖區(qū)中。如果遠程系統(tǒng)的同一層確認了正確接收，重傳緩沖區(qū)將被釋放，然而，如果一個"NACK"發(fā)生，協(xié)議層重傳緩沖區(qū)的內(nèi)容，同時再分配一個重傳緩沖區(qū)，拷貝內(nèi)容至重傳緩沖區(qū)。

如果已經(jīng)發(fā)出的包可以被協(xié)議層標記為"Unmarked"或"Reserved"的話，上述機制就可被取消，這種情況僅保存一個指針而不拷貝。當設備驅(qū)動程序完成傳送包并試圖釋放緩沖區(qū)，緩沖區(qū)系統(tǒng)確認此緩沖區(qū)保留，并不釋放包，僅僅將它標記為"已傳輸",當相應的協(xié)議層收到確認（ACK）之后，就把包去掉標識，并且釋放緩沖區(qū)，通過把這一特性固化至網(wǎng)絡服務模塊中，整個協(xié)議棧的效率將大大提高。

4細節(jié)

任何合理的基于驅(qū)動程序的協(xié)議棧都會包含相似的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)和控制原語及模塊函數(shù)。下面介紹一下細節(jié)數(shù)據(jù)結(jié)構(gòu)，以下是一些可能用到的數(shù)據(jù)結(jié)構(gòu)。

（1）設備入口提供實時操作系統(tǒng)和某一特殊的協(xié)議模塊的管道；

（2）驅(qū)動程序靜態(tài)變量對于每一協(xié)議層僅分配，不管協(xié)議層下的網(wǎng)絡接口有多少，它是協(xié)議層的全局存儲區(qū)域；

（3）邏輯單位靜態(tài)變量僅基于接口分配，所以如果你有一個設備驅(qū)動程序控制兩個接口，就應有兩個邏輯單位靜態(tài)變量，但是僅有一個驅(qū)動程序變量和一個設備條目數(shù)據(jù)結(jié)構(gòu)；

（4）路徑變量基于應用程序?qū)f(xié)議的調(diào)用，僅分配。

基于上述四種定義，協(xié)議中的各種數(shù)據(jù)應被定義為合適的類型，被選定的數(shù)據(jù)結(jié)構(gòu)應當基于這個變量如何被使用：