袁瑞成，劉 波，喬 磊，劉健培

0 引 言

目前中國在軌運行的大部分航天器內(nèi)部各個計算機(jī)之間是通過總線進(jìn)行互聯(lián)的，網(wǎng)絡(luò)應(yīng)用在我國航天器上還處于空白.隨著載人三期、探月三期等重大專項的實施，特別是空間站的建設(shè)，航天器整個系統(tǒng)的規(guī)模越來越龐大，各個計算機(jī)系統(tǒng)之間聯(lián)系越來越密切，執(zhí)行的任務(wù)越來越復(fù)雜.現(xiàn)有使用總線來連接各個計算機(jī)的通信方式已不能滿足應(yīng)用需求.因此利用網(wǎng)絡(luò)來實現(xiàn)各個計算機(jī)系統(tǒng)之間的通訊勢在必行，研究航天領(lǐng)域的專用網(wǎng)絡(luò)協(xié)議具有重要的工程應(yīng)用價值.

目前航天器內(nèi)部各個系統(tǒng)之間的通訊主要分兩種數(shù)據(jù)包，一種是控制數(shù)據(jù)包，用于傳遞各個模塊間的控制信息，另一種是普通數(shù)據(jù)包，主要是傳遞各個模塊之間正常通訊數(shù)據(jù).在航天器上，數(shù)據(jù)包小，數(shù)量眾多的控制數(shù)據(jù)包占有很大比例.控制數(shù)據(jù)包主要是用于向某一模塊發(fā)送控制信號，控制數(shù)據(jù)包對數(shù)據(jù)傳輸?shù)膶崟r性要求很高.航天器對數(shù)據(jù)傳輸?shù)目煽啃砸蠛芨?，?shù)據(jù)在傳輸過程中必須保證數(shù)據(jù)的正確性和完整性.設(shè)計專用的TCP/IP協(xié)議棧并且移植到大量使用的空間操作系統(tǒng)SpaceOS2上是非常有必要的.

1 關(guān)于TCP/IP協(xié)議棧

1.1 協(xié)議棧標(biāo)準(zhǔn)的選擇

選擇業(yè)界常用的TCP/IP協(xié)議棧有BSD,Linux,LwIP,UIP,Uc/IP,NicheStrack等，其對比如表1-1所示.

除去商業(yè)協(xié)議棧，開源協(xié)議棧中比較輕量級的是LwIP、Uc/IP、uIP，復(fù)雜一些的是BSD和Linux協(xié)議棧.

按照協(xié)議特性豐富程度排序，大致是：

Linux協(xié)議棧> BSD協(xié)議棧>LwIP>Uc/IP>uIP

代碼大小的順序也大致是：

Linux協(xié)議棧> BSD協(xié)議棧>LwIP>Uc/IP>uIP

首先Linux協(xié)議棧與Linux其余部分關(guān)系復(fù)雜，協(xié)議棧模型自成一家，基本不具備移植到其余操作系統(tǒng)的可能.其次uIP功能過于簡單，比較適合沒有操作系統(tǒng)的場景.最后，Uc/IP綁定到了UCOS，以后可能會有License授權(quán)問題，而且協(xié)議棧模型與BSD相似，見表1所示.與LwIP相比，BSD協(xié)議棧的特性是(同時也是BSD協(xié)議棧代碼更大的原因)下列四條.

1) 支持動態(tài)IP路由：LwIP支持IP轉(zhuǎn)發(fā)，但是不支持動態(tài)IP路由；

2) BSD協(xié)議棧具有高實時高性能的同時可以壓縮到較小的體積.

3) 支持大量已有的網(wǎng)絡(luò)應(yīng)用程序：大部分的網(wǎng)絡(luò)應(yīng)用程序的接口都是兼容于BSD Socket API的，同時可能會有大量POSIX文件系統(tǒng)的接口，而BSD協(xié)議棧基于Unix，日后增加文件系統(tǒng)接口相對容易；

4) 使用者眾多，不論是從Unix派生的老牌桌面或服務(wù)器系統(tǒng)(如OpenBSD、netBSD、freeBSD等)，還是路由器操作系統(tǒng)，(如思科IOS，最新版思科IOS XR使用QNX的協(xié)議棧，而QNX的協(xié)議棧來源于netBSD；JunOS操作系統(tǒng)，基于freeBSD)，還是典型的RTOS，(如VxWorks、RTEMS、QNX、LynxOS等)，使用的都是BSD的協(xié)議棧.經(jīng)過多年的使用和測試，BSD協(xié)議棧的健壯性、穩(wěn)定性、性能都有一定的保證，并且以后為擴(kuò)展其他功能例如防火墻接口提供了重要的支持.

表1 協(xié)議棧對比表Tab.1 Protocol stackcontrast table

如果只是需要通過IP接入網(wǎng)絡(luò)，而且內(nèi)存等資源也很有限，那么LwIP將是個不錯的選擇，而且LwIP的移植相對簡單得多.如果需要支持動態(tài)IP路由、復(fù)雜的網(wǎng)絡(luò)應(yīng)用程序，BSD協(xié)議棧是個更好的選擇.

從以上角度考慮，本文使用BSD協(xié)議棧作為移植原型.

1.2 協(xié)議棧版本的選擇

圖1顯示了各種BSD版本的年表，包括重要的TCP/IP特征.顯示在左邊的版本是公開可用源代碼版，它包括所有聯(lián)網(wǎng)代碼：協(xié)議本身、聯(lián)網(wǎng)接口的內(nèi)核例程及很多應(yīng)用和實用程序(如Telnet和FTP等).

在BSD因資助問題停止開發(fā)前，最終停留的版本是4.4BSD-Lite Release 2.這是特性最豐富(如新的擁塞控制算法、多播、“長肥管道”修改以及其他類似的研究特性)，也最穩(wěn)定的版本，基本上后續(xù)“伯克利派生系統(tǒng)”(指SunOS4.x、SVR4、 AIX、FreeBSD、NetBSD等基于伯克利源代碼開發(fā)的系統(tǒng))都使用該版本作為基線版本.

所以，最終確定本文的TCP/IP協(xié)議棧移植源是4.4BSD-Lite Release 2.

1.3 協(xié)議棧體系結(jié)構(gòu)

復(fù)雜的數(shù)據(jù)通信系統(tǒng)不是使用單一的協(xié)議來處理所有的傳輸任務(wù)，而是一整套相互合作的協(xié)議，這些協(xié)議合稱協(xié)議族.協(xié)議族通常使用分層的概念設(shè)計和實現(xiàn)，所以又稱協(xié)議棧.TCP/IP協(xié)議軟件在概念上分成4層，而在一個實際的系統(tǒng)中實現(xiàn)協(xié)議棧時，要顧及到具體硬件接口、OS特性與接口、緩沖區(qū)管理、協(xié)議之間的接口、錯誤處理等細(xì)節(jié)，協(xié)議軟件的模塊結(jié)構(gòu)比概念結(jié)構(gòu)要復(fù)雜.

1.3.1 TCP/IP協(xié)議棧的分層概念結(jié)構(gòu)

網(wǎng)絡(luò)協(xié)議通常分不同層次進(jìn)行開發(fā)，每一層分別負(fù)責(zé)不同的通信功能.一個協(xié)議族，比如TCP/IP，是一組不同層次上的多個協(xié)議的組合.TCP/IP通常被認(rèn)為是一個四層協(xié)議系統(tǒng)，如圖2所示.每一層負(fù)責(zé)不同的功能：

1) 鏈路層，有時也稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層，通常包括操作系統(tǒng)中的設(shè)備驅(qū)動程序和計算機(jī)中對應(yīng)的網(wǎng)絡(luò)接口卡.它們一起處理與電纜(或其他任何傳輸媒介)的物理接口細(xì)節(jié).

2) 網(wǎng)絡(luò)層，有時也稱作互聯(lián)網(wǎng)層，處理分組在網(wǎng)絡(luò)中的活動，例如分組的選路.在TCP/IP協(xié)議族中，網(wǎng)絡(luò)層協(xié)議包括IP協(xié)議(網(wǎng)際協(xié)議)，ICMP協(xié)議(網(wǎng)際控制報文協(xié)議)，以及IGMP協(xié)議(網(wǎng)際組管理協(xié)議).

3) 傳輸層，主要為兩臺主機(jī)上的應(yīng)用程序提供端到端的通信.在TCP/IP協(xié)議族中，有兩個互不相同的傳輸協(xié)議：TCP(傳輸控制協(xié)議)和UDP(用戶數(shù)據(jù)報協(xié)議).TCP為兩臺主機(jī)提供高可靠性的數(shù)據(jù)通信.它所做的工作包括把應(yīng)用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡(luò)層，確認(rèn)接收到的分組，設(shè)置發(fā)送最后確認(rèn)分組的超時時鐘等.由于運輸層提供了高可靠性的端到端的通信，因此應(yīng)用層可以忽略所有這些細(xì)節(jié).而另一方面，UDP則為應(yīng)用層提供一種非常簡單的服務(wù).它只是把稱作數(shù)據(jù)報的分組從一臺主機(jī)發(fā)送到另一臺主機(jī)，但并不保證該數(shù)據(jù)報能到達(dá)另一端.任何必需的可靠性必須由應(yīng)用層來提供.這兩種運輸層協(xié)議分別在不同的應(yīng)用程序中有不同的用途.

4) 應(yīng)用層，負(fù)責(zé)處理特定的應(yīng)用程序細(xì)節(jié).如Telnet 遠(yuǎn)程登錄、FTP 文件傳輸協(xié)議等通用的應(yīng)用程序.

從概念上講，從一臺設(shè)備的應(yīng)用程序向另一臺設(shè)備的應(yīng)用程序發(fā)送一個報文，意味著這樣一個過程：該報文在發(fā)送設(shè)備的協(xié)議軟件中逐層下行，通過網(wǎng)絡(luò)轉(zhuǎn)發(fā)，再在接收設(shè)備的協(xié)議軟件中逐層上行.

以以太網(wǎng)中2臺運行FTP協(xié)議的設(shè)備之間的通信為例，圖3說明了通信過程需要涉及到的所以協(xié)議，以及協(xié)議報文的處理過程.

1.3.2 TCP/IP協(xié)議軟件的模塊實現(xiàn)結(jié)構(gòu)

具體到本文，是要在SpaceOS上實現(xiàn)TCP/IP協(xié)議棧，那么除了協(xié)議棧本身各個協(xié)議的邏輯外，還需要考慮到以下多個方面：

(1) 接口方面

1) 與硬件接口卡的接口：使用統(tǒng)一的END驅(qū)動模型，協(xié)議棧通過MUX層與END驅(qū)動通信.

2) 與SpaceOS的接口：網(wǎng)絡(luò)任務(wù)的管理、信號量提供互斥與同步、開關(guān)中斷保護(hù)臨界數(shù)據(jù)、定時中斷以實現(xiàn)定時器、協(xié)議棧內(nèi)存池的分配與釋放.

3) 應(yīng)用接口：應(yīng)用程序使用socket接口與協(xié)議棧通信.

(2) 協(xié)議棧的實現(xiàn)方面

1) 緩沖區(qū)管理：使用mBlk-clBlk-Cluster的三級緩沖區(qū)管理結(jié)構(gòu).

2) 定時器：使用time sheel(時間輪)算法實現(xiàn)軟件定時器.

3) 協(xié)議之間的接口：使用protosw等數(shù)據(jù)結(jié)構(gòu)將接口抽象化(協(xié)議之間通過函數(shù)指針，而不是直接調(diào)用函數(shù)名).

4) 協(xié)議棧代碼的組織：協(xié)議本身的實現(xiàn)代碼、協(xié)議與OS驅(qū)動等的接口代碼、協(xié)議用到的例程分、初始化與剪裁代碼，分成不同的文件夾組織.

(3) 測試、演示與驗證方面

1) 在協(xié)議棧之外實現(xiàn)FTP、TFTP、Telnet、Http(以及Web Server)、Yaffs文件系統(tǒng)、flash驅(qū)動等模塊.

(4) 代碼質(zhì)量方面

1) 模塊間的耦合性：OS、應(yīng)用程序、硬件驅(qū)動、協(xié)議之間等接口都盡量解耦.

2) 代碼大小與裁剪性：通過用函數(shù)指針以及宏控制初始化函數(shù)的辦法剪裁代碼.

3) 性能：使用獨立的網(wǎng)絡(luò)處理任務(wù)、緩沖隊列、高效的路由查找算法等提高性能.

4) 可靠性：使用心跳監(jiān)視網(wǎng)絡(luò)任務(wù)、減少任務(wù)狀態(tài)等方式提高可靠性.

最終，在SpaceOS上實現(xiàn)TCP/IP協(xié)議棧的實現(xiàn)結(jié)構(gòu)如圖4所示：

其中，整個實現(xiàn)的核心是TCP/IP協(xié)議棧本身的邏輯代碼，而TCP/IP的核心又是IP.

應(yīng)用層通過Socket層使用協(xié)議棧，而協(xié)議棧通過MUX層與驅(qū)動層通信.

整個協(xié)議棧使用單獨的一個網(wǎng)絡(luò)任務(wù)netTask處理所有數(shù)據(jù)包的接收和處理，具體過程如下：

1) netTask與驅(qū)動通過環(huán)形工作隊列和信號量進(jìn)行通信；

2) netTask根據(jù)數(shù)據(jù)包中的MAC頭(鏈路層)中類型字段決定將包放入ARP隊列還是IP輸入隊列；

3) IP層根據(jù)IP頭中的類型字段決定調(diào)用ICMP處理ICMP子類型、IGMP、還是送往UDP或者TCP隊列，根據(jù)目的IP地址決定數(shù)據(jù)包的去向(送往上層處理、轉(zhuǎn)發(fā)、丟棄、組播)；

4) UDP(TCP)通過UDP(TCP)頭中的端口號決定將包送往對應(yīng)的Socket隊列.

5) 如果相應(yīng)Socket隊列有應(yīng)用層任務(wù)在等待接收，則釋放信號量，然后應(yīng)用任務(wù)通過Socket隊列接收數(shù)據(jù).

應(yīng)用層發(fā)送數(shù)據(jù)時，通過Socket調(diào)用UDP/TCP的輸出函數(shù)，然后UDP/TCP添加頭后，調(diào)用IP層的輸出函數(shù)，IP層通過目的IP查找路由，決定數(shù)據(jù)包的輸出接口，并通過ARP過程獲得IP地址對應(yīng)的MAC地址，然后將包送入對應(yīng)輸出接口的隊列中，最后調(diào)用驅(qū)動的輸出函數(shù)將隊列中的數(shù)據(jù)包發(fā)送出去.整個過程都使用函數(shù)調(diào)用，即發(fā)生在應(yīng)用層任務(wù)的環(huán)境中.

除協(xié)議棧的實現(xiàn)外，應(yīng)用層有TFTP、FTP、Telnet、HTTP 4個任務(wù)實現(xiàn)4個協(xié)議和應(yīng)用邏輯.

協(xié)議相關(guān)部分與SpaceOS的接口通過一個統(tǒng)一的接口文件解耦，協(xié)議部分的代碼只使用該文件中的函數(shù)，而與SpaceOS隔離開來.

應(yīng)用層程序都需要使用到文件系統(tǒng)，本文使用YAFFS這個與基本不需要操作系統(tǒng)文件操作支持的Flash文件系統(tǒng).

在YAFFS與應(yīng)用程序之間有薄薄的一層文件系統(tǒng)接口，該接口同時也支持對協(xié)議棧的控制操作.

2 傳輸層的設(shè)計

本節(jié)介紹一下傳輸層的具體設(shè)計實現(xiàn)，傳輸層數(shù)據(jù)包格式的如圖5所示.

其中：

1) 本地地址和本地端口域表示發(fā)送數(shù)據(jù)包一方；

2) 目的地址和目的端口域表示接受數(shù)據(jù)包一方；

3) 序列號域表示發(fā)送方發(fā)送數(shù)據(jù)包的序號；

4) 確認(rèn)號域用于對最新收到的一個數(shù)據(jù)包的確認(rèn)回答；

5) 數(shù)據(jù)包ACK位被設(shè)置為1，表明數(shù)據(jù)包是確認(rèn)數(shù)據(jù)包；

6) 建立連接的時，數(shù)據(jù)包SYN置為1，表示數(shù)據(jù)包是請求建立連接的數(shù)據(jù)包；

7) 釋放一個連接時，數(shù)據(jù)包FIN置為1，表示數(shù)據(jù)包是釋放連接的數(shù)據(jù)包；

8) RST位被置為1，用于重置一個混亂的連接，也可用于拒絕一個連接請求；

9) 優(yōu)先級域是用4位表示該數(shù)據(jù)包在網(wǎng)絡(luò)中傳輸?shù)膬?yōu)先級，網(wǎng)絡(luò)中節(jié)點在傳輸數(shù)據(jù)包時，會根據(jù)數(shù)據(jù)包的優(yōu)先級，優(yōu)先傳輸高優(yōu)先級的數(shù)據(jù)包；

10) 校驗和域用于校驗數(shù)據(jù)包；

11) 數(shù)據(jù)域就是存放要傳輸?shù)臄?shù)據(jù).

2.1 傳輸層套接字

網(wǎng)絡(luò)節(jié)點在傳輸層主要是用套接字來控制，通過套接字可以查看網(wǎng)絡(luò)連接相關(guān)的信息.套接字的數(shù)據(jù)結(jié)構(gòu)如下：

typedef struct sock{

struct sock *pre;

struct sock *next;

unsigned char dest_addr;

unsigned char local_addr;

unsigned char dest_port;

unsigned char local_port;

unsigned char sock_state;

unsigned char priority;struct tp_cb *trans_control_block;

unsigned int sock_sequence;

unsigned int sock_count;

SEM_ID sock_semid;

unsigned int sock_have_data;

}SOCKET;

2.2 傳輸層連接創(chuàng)建

使用3次握手過程創(chuàng)建一個新連接，如圖6所示，發(fā)送方向接收方發(fā)送一個SYN數(shù)據(jù)包，然后一直處于睡眠狀態(tài)，直到收到接收方返回的ACK數(shù)據(jù)包；發(fā)送方再次向接收方發(fā)送一個ACK數(shù)據(jù)包這樣才建立了一個新的連接.如果在指定的時間內(nèi)發(fā)送方無法收到ACK數(shù)據(jù)包，就會重新發(fā)送一個SYN數(shù)據(jù)包.如此嘗試若干次之后仍然無法建立連接就停止連接，并向上層應(yīng)用提示無法建立連接.在建立連接的過程中，SYN數(shù)據(jù)包的優(yōu)先級由套接字中優(yōu)先級確定的，網(wǎng)絡(luò)中節(jié)點在轉(zhuǎn)發(fā)數(shù)據(jù)包的時候會根據(jù)數(shù)據(jù)包優(yōu)先級由高到低的次序轉(zhuǎn)發(fā)數(shù)據(jù)包.

2.3 傳輸層數(shù)據(jù)傳輸

數(shù)據(jù)傳輸模塊主要是由接收數(shù)據(jù)和發(fā)送數(shù)據(jù)兩個處理過程構(gòu)成.

發(fā)送數(shù)據(jù)過程：將指定要發(fā)送的數(shù)據(jù)分割成若干個數(shù)據(jù)包，將數(shù)據(jù)包按照數(shù)據(jù)組織的先后順序連續(xù)分配序號.在發(fā)送一個數(shù)據(jù)包之后，直到接收方返回確認(rèn)包才會發(fā)送下一個數(shù)據(jù)包，否則等待超時重新發(fā)送此數(shù)據(jù)包.

從指定的連接上接受數(shù)據(jù)：接收到一個數(shù)據(jù)包之后，校驗數(shù)據(jù)的完整性和正確性后，向發(fā)送方發(fā)送一個包含下一個想要接收數(shù)據(jù)包的序號的確認(rèn)數(shù)據(jù)包，將接收到數(shù)據(jù)包按照序號的先后順序?qū)?shù)據(jù)合并成完整的數(shù)據(jù)，并存放到指定的位置.

在數(shù)據(jù)傳輸?shù)倪^程中，數(shù)據(jù)包按照分配的序號依次向網(wǎng)絡(luò)中發(fā)送數(shù)據(jù)包，其中數(shù)據(jù)包中包含優(yōu)先級，用來滿足實時數(shù)據(jù)傳輸?shù)囊?當(dāng)有實時數(shù)據(jù)傳送的時候，將數(shù)據(jù)包分配高優(yōu)先級.當(dāng)網(wǎng)絡(luò)中節(jié)點接收到數(shù)據(jù)包時，就根據(jù)數(shù)據(jù)包的優(yōu)先級對數(shù)據(jù)包重新排序，高優(yōu)先級的數(shù)據(jù)包網(wǎng)絡(luò)節(jié)點將優(yōu)先轉(zhuǎn)發(fā).這樣就保證了實時數(shù)據(jù)能夠及時傳輸.

當(dāng)一個數(shù)據(jù)包n發(fā)送后，發(fā)送方就會設(shè)置一個定時器，如果在指定的時間中無法接受到接收方返回的數(shù)據(jù)包n的確認(rèn)數(shù)據(jù)包，發(fā)送方就會重新發(fā)送數(shù)據(jù)包n，在經(jīng)過若干次重復(fù)之后仍無法接收到確認(rèn)數(shù)據(jù)包，發(fā)送方就認(rèn)定接收方已失效，就會斷開連接，見圖7所示.

2.4 傳輸層連接釋放

釋放指定的連接：使用四次握手過程來釋放一個連接.為了釋放一個連接，任何一方都可以發(fā)送一個設(shè)置了FIN位的數(shù)據(jù)包，它表示沒有數(shù)據(jù)需要發(fā)送，當(dāng)另一方接受到FIN數(shù)據(jù)包時就會向?qū)Ψ椒呕匾粋€ACK數(shù)據(jù)包并也發(fā)送一個FIN數(shù)據(jù)包.這兩個數(shù)據(jù)包可以合并為同一個數(shù)據(jù)包.當(dāng)對方接受FIN數(shù)據(jù)包時就會再返回一個ACK數(shù)據(jù)包.最后經(jīng)過如此四次握手之后，才能釋放一個連接，見圖8所示.

3 移植過程

本模塊實現(xiàn)移植BSD協(xié)議棧需要的OS功能函數(shù)，包括：網(wǎng)絡(luò)任務(wù)的管理、信號量提供互斥與同步、開關(guān)中斷保護(hù)臨界數(shù)據(jù)、定時中斷以實現(xiàn)定時器、協(xié)議棧內(nèi)存池的分配與釋放.

另外，添加網(wǎng)絡(luò)應(yīng)用程序時，還需要實現(xiàn)消息隊列、時間管理、一部分C庫函數(shù)等.

3.1 模塊化設(shè)計

主要設(shè)計思路是：實現(xiàn)一個單獨的接口文件，這個文件調(diào)用SpaceOS的函數(shù)實現(xiàn)接口，所有新增的代碼只依賴于這個接口文件，不允許直接調(diào)用SpaceOS的函數(shù)，同時做到調(diào)用SpaceOS函數(shù)的最小化，這樣，就保證了新增代碼與SpaceOS二者的相對獨立性，當(dāng)修改新增代碼、修改SpaceOS代碼、或者裁剪代碼時，可以很容易的完成.

3.2 模塊接口實現(xiàn)

3.2.1 模塊接口

接口包括：任務(wù)管理接口函數(shù)，中斷管理接口函數(shù)，消息隊列管理接口函數(shù)，內(nèi)存管理接口函數(shù)，時間管理接口函數(shù)，定時器中斷回調(diào)函數(shù)(圖9).

具體接口代碼示例：

∥VxWorks任務(wù)創(chuàng)建接口：

int taskSpawn

(

char *name,

int priority,

int options,

int stackSize,

FUNCPTR entryPt,

int arg1, int arg2,int arg3,int arg4,int arg5,int arg6,

int arg7,int arg8,int arg9,int arg10

);

STATUStaskDelete

(int tid);

STATUStaskSuspend

(int tid);

STATUStaskResume

(inttid);

STATUStaskDelay

(int ticks);

int taskIdSelf (void);

STATUStaskLock (void);

STATUStaskUnlock (void);

int vx_get_taskIdCurrent(void);

SEM_ID vx_get_taskIdCurrent_selectSem(void);

∥中斷管理接口函數(shù)：

STATUSintConnect (VOIDFUNCPTR *vector, VOIDFUNCPTR routine,int parameter);

int intLock (void);

int intUnlock (int oldSR);

BOOL intContext (void);

∥內(nèi)存管理接口函數(shù)：

void *malloc (size_t nBytes)

void free (void *ptr);

∥消息隊列管理接口函數(shù)：

MSG_Q_ID msgQCreate (int maxMsgs, int maxMsgLength, int options);

STATUSmsgQDelete(MSG_Q_ID sgQId);

STATUSmsgQSend (MSG_Q_ID msgQId, char *buffer, UINT nBytes, int timeout, int priority);

int msgQReceive (MSG_Q_ID msgQId, char *buffer, UINT maxNBytes,int timeout);

∥定時器中斷回調(diào)函數(shù)：

void OS_TickHook(void)

{

hardclock_tick_callback();

}

∥SpaceOS2任務(wù)創(chuàng)建接口：

int ret;

ret = OSTaskSpawn((unsigned int)name, (unsigned int)priority, (unsigned int)0, (unsigned int)stackSize,

taskWrapper, arg1, arg2, arg3, (int)entryPt);

if(NULL == ret)

{}

return ret;

3.2.2 模塊實現(xiàn)

整個接口函數(shù)集合在bsd_port_if.c中實現(xiàn).

總共實現(xiàn)了如圖10的函數(shù).

其中調(diào)用函數(shù)入口部分代碼為：

static int taskWrapper(

register int arg1,

register int arg2,

register int arg3,

register int arg4)

{

FUNCPTR realTaskEntryPt = (FUNCPTR)arg4;

(*realTaskEntryPt)(arg1, arg2, arg3);

#ifndef MODIFY_FOR_DEBUG

taskSuspend(0);

#else

taskDelete(0);

#endif

}

taskSpawn的是VxWorks系統(tǒng)中的任務(wù)創(chuàng)建接口，因為直接將其移植時會導(dǎo)致各種不可預(yù)料的關(guān)聯(lián)問題，所以將其進(jìn)行接口替換的操作，如移植到SpaceOS2的系統(tǒng)接口上原理圖11所示.

另外，C庫的接口的在libc目錄下，這一部分代碼與OS關(guān)系不大，更多的是與編譯器有關(guān).

4 性能測試實驗結(jié)果

基本的測試場景如圖12所示.目標(biāo)板使用BM3803處理器，主頻設(shè)置為66 M，使用SpaceOS2操作系統(tǒng).性能測試的主要目標(biāo)是通過測試得出協(xié)議棧的性能指標(biāo)，分析性能瓶頸.所以將采用對比的方式進(jìn)行測試.

協(xié)議棧在目標(biāo)板上運行時，如果從應(yīng)用層發(fā)送數(shù)據(jù)，數(shù)據(jù)將通過路徑“UDP/TCP層->IP層->網(wǎng)卡驅(qū)動->網(wǎng)卡”發(fā)出；如果將目標(biāo)板用作路由，數(shù)據(jù)將通過路徑“網(wǎng)卡->網(wǎng)卡驅(qū)動->IP層->網(wǎng)卡驅(qū)動->網(wǎng)卡”轉(zhuǎn)發(fā).在此過程中，除去應(yīng)用本身，性能度量有網(wǎng)卡IO讀寫性能、網(wǎng)卡驅(qū)動性能、IP層性能、UDP /TCP層性能.這些性能度量受多方面的參數(shù)影響.

1) 硬件配置方面：如CPU的頻率、CPU與網(wǎng)卡的總線寬度和接口方式、是否支持DMA等.

2) 軟件配置方面：如驅(qū)動設(shè)計方式、協(xié)議棧緩沖區(qū)大小、代碼是否在RAM中運行、是否啟用CACHE等.

3) 系統(tǒng)級別方面：如網(wǎng)絡(luò)環(huán)境、對端設(shè)備速率等.

主要測試協(xié)議棧不同層次(涉及單向傳輸與轉(zhuǎn)發(fā)2種)在不同幀長、CACHE是否使能、CPU主頻、指令運行在RAM/FLASH等參數(shù)影響下的性能度量.

測試結(jié)論如下：

以主頻66 M，程序運行在RAM中為例，不同CACHE狀態(tài)下轉(zhuǎn)發(fā)速率(IP路由)與單向發(fā)送速率的關(guān)系如表2(平均幀長約1 000字節(jié))所示.

表2 轉(zhuǎn)發(fā)速率與單向發(fā)送速率對比(主頻66 M，程序運行于RAM)Tab.2 The comparison of retransmission and one-way transmission

① 轉(zhuǎn)發(fā)速率約是單向傳輸速率的一半;

② CACHE對協(xié)議棧性能影響較大.指令CACHE對性能影響最大，約是數(shù)據(jù)CACHE影響的一倍.開關(guān)數(shù)據(jù)/指令CACHE對速率的影響比例約是“關(guān)數(shù)據(jù)CACHE+關(guān)指令CACHE：開數(shù)據(jù)CACHE+關(guān)指令CACHE：關(guān)數(shù)據(jù)CACHE+開指令CACHE：開數(shù)據(jù)CACHE+開指令CACHE=1∶1.5∶3∶5”;

③ 主頻大小與性能高低成穩(wěn)定的正比，基本上主頻增加一倍，吞吐率也增加一倍;

④ 對當(dāng)前目標(biāo)板而言，影響協(xié)議性能最大的瓶頸在于網(wǎng)卡IO處.首先，因為DM9000是通過IO方式讀寫數(shù)據(jù)的，每個字(16bits)都需要用讀寫指令移動數(shù)據(jù)，其次，因為sparc的字節(jié)序與DM9000字節(jié)序相反，每個字在移動前需要交換順序(表中DRV-MAC的差異即時交換順序?qū)е碌乃俾什町?;

⑤ 程序運行在RAM中吞吐率是運行在FLASH中的一倍多.但是如果打開指令CACHE，則吞吐率相差不大.說明只要指令CACHE命中率高，基本上讀FLASH的IO速率就不會成為瓶頸(表3);

⑥ 長幀吞吐率明顯高于短幀.越小的幀由于前導(dǎo)碼、幀間隔和處理總幀數(shù)的原因，其吞吐量就越低;

⑦ 協(xié)議棧的IP層與UDP層速率相差不大，而TCP層則相差較多.主要是因為TCP是可靠連接，協(xié)議復(fù)雜，處理量大，數(shù)據(jù)的確認(rèn)機(jī)制等導(dǎo)致的.各層吞吐率比例約是“IP層∶UDP層∶TCP層的=10∶9∶7”;

⑧ 一些指標(biāo)數(shù)據(jù)

吞吐率:在目標(biāo)板上，如果主頻設(shè)置為66 M，數(shù)據(jù)CACHE與指令CACHE全開，將程序運行在RAM中，能得到最高的吞吐率：IP層24.7 Mb/s，UDP層22.1 Mb/s，TCP層16.8 Mb/s.如果主頻設(shè)置為66 M，數(shù)據(jù)CACHE與指令CACHE全關(guān)，將程序運行在FLASH中，能得到的吞吐率：IP層4.5 Mb/s，UDP層4.1 Mb/s，TCP層3.5 Mb/s.

表3 程序運行在RAM與運行在FLASH中對比(主頻66 M，包長1 464)Tab.3 Program running in RAM and FLASH

丟幀率:在協(xié)議棧吞吐量臨界區(qū)域，丟幀率小于0.5%(實測平均約0.2%-0.4%).

時延:對點傳輸，IP層時延小于5 ms(實測平均約1～3 ms)，UDP層時延小于5 ms(實測平均約3～5 ms)，TCP層連接建立時延小于5 ms(實測平均約3～5 ms)，TCP層數(shù)據(jù)時延小于10 ms(實測平均約3～8 ms).

突發(fā)數(shù)據(jù)量:大于50幀.具體與幀長和緩沖區(qū)配置有關(guān)，實測約100 K數(shù)據(jù)量.

5 結(jié) 論

隨著中國航天工程的不斷深入，網(wǎng)絡(luò)應(yīng)用必然會在以后的航天型號中得到廣泛應(yīng)用，針對航天型號任務(wù)的特殊應(yīng)用需求，設(shè)計適合航天領(lǐng)用應(yīng)用的自主可控操作系統(tǒng)及網(wǎng)絡(luò)協(xié)議具有重要的意義.本文結(jié)合當(dāng)前控制數(shù)據(jù)包傳輸量大、數(shù)據(jù)包小以及實時性要求高的特點，改進(jìn)優(yōu)化了BSD協(xié)議，并將其移植到使用率很高的SpaceOS2上，可以滿足航天型號對控制數(shù)據(jù)包實時性高的要求，實現(xiàn)了在自主研發(fā)操作系統(tǒng)上之上的網(wǎng)絡(luò)數(shù)據(jù)傳輸目的.本文工作已在某航天型號計算機(jī)上進(jìn)行了測試驗證，取得了較好的效果.