嵌入式Linux通信中構件技術(shù)應用研究

考慮到TCP 協(xié)議是面向連接的、端對端的可靠通信協(xié)議，為保證遠程客戶(hù)端與本地嵌入式系統服務(wù)器的正確通信，采取了相應機制來(lái)保證它的可靠性和實(shí)時(shí)性，即連接的建立與關(guān)閉、超時(shí)重傳機制、數據包確認機制、流量控制等。因此，將TCP 協(xié)議按應用功能劃分成客戶(hù)端模塊和服務(wù)器端模塊，前者主動(dòng)建立連接，后者*連接，連接建立后雙方進(jìn)行數據信息的發(fā)送或接收。

相對于TCP 協(xié)議，ARP、IP、ICMP、UDP 等協(xié)議功能較簡(jiǎn)單，對它們不劃分模塊，每個(gè)協(xié)議按其完成的功能設計成一個(gè)構件，但考慮到嵌入式系統的實(shí)時(shí)性，去掉了不必要的功能。UDP 協(xié)議設計時(shí)不考慮數據校驗方法，只考慮數據的發(fā)送和接收功能。ICMP 協(xié)議設計時(shí)僅考慮了目的端不可達、源端抑制、超時(shí)、改變路由等差錯和回送請求處理。IP 協(xié)議設計時(shí)主要進(jìn)行路由、向相鄰協(xié)議層傳遞數據包，而不考慮分片、重裝功能。ARP 協(xié)議主要負責將局域網(wǎng)中的32 位IP 地址轉換為對應的網(wǎng)卡的MAC 地址，它的功能包括發(fā)送ARP 請求和響應對方的ARP 請求，動(dòng)態(tài)維護一個(gè)ARP 高速緩存。

3.1.3 通信協(xié)議構件組裝

通信協(xié)議構件組裝過(guò)程如圖2 所示。通信協(xié)議構件放在構件庫中，系統運行時(shí)，嵌入式Linux 操作系統調度協(xié)議組裝模塊，由該模塊依據系統網(wǎng)絡(luò )功能需求從構件庫中取出相應構件，動(dòng)態(tài)配置通信協(xié)議棧。

嵌入式Linux 操作系統

因此，組裝的主要功能是負責實(shí)現嵌入式Linux 操作系統和構件庫的交互、監控構件的運行狀況，并記錄構件的特征以反饋給構件庫。

3.2 通信協(xié)議構件化的實(shí)現本文借鑒文獻[5]的思想，并結合上面提出的方法來(lái)實(shí)現通信協(xié)議構件化。各協(xié)議的實(shí)現類(lèi)似，下面以TCP 協(xié)議為例說(shuō)明實(shí)現過(guò)程。

將協(xié)議棧初始化文件中為協(xié)議分配內核存儲空間、向內核保存TCP 協(xié)議棧的鏈表結構、注冊、協(xié)議本身初始化的內容移入其模塊中，在模塊開(kāi)始部分完成分配存儲空間、注冊、初始化等，在模塊結束部分完成釋放模塊所占內核空間、取消注冊、進(jìn)行重置等。

修改協(xié)議實(shí)現文件tcp.c 和tcp.h ，創(chuàng )建新的模塊文件，協(xié)議實(shí)現文件中僅保留被其它協(xié)議使用的變量，其它內容放在新建的模塊文件中。

協(xié)議提供給其它協(xié)議的函數接口，由函數名調用改為函數指針調用，修改頭文件，為該新的接口實(shí)現添加定義及聲明，并將函數指針初始化指向一個(gè)空函數體。將其它協(xié)議中原來(lái)通過(guò)函數名調用改為相應的函數指針調用，這些函數指針是該協(xié)議構件的接口，可以保持不變，而接口提供的功能可以依據需要隨時(shí)修改。

修改網(wǎng)絡(luò )部分的內核符號表文件，既包括修改之后為其它協(xié)議提供的接口，又包括模塊化之后需要的其它協(xié)議提供的接口。

修改Makeflie 文件，增加相應的模塊化文件列表。

4 通信協(xié)議測試

構件化的協(xié)議的運行情況在MagicARM2200 目標板上進(jìn)行測試，測試前需要配置軟硬

件環(huán)境，配置過(guò)程如下：用串口線(xiàn)和簡(jiǎn)易仿真器連接PC 機和目標板，使用兩條獨立的網(wǎng)線(xiàn)分別將它們連接到以太網(wǎng);在PC 機上安裝虛擬機5.5 和Red Hat Linux 9 ，將經(jīng)過(guò)實(shí)時(shí)改進(jìn)和裁剪的Linux 移植到該目標板。

4.1 測試ARP 協(xié)議構件

在內核無(wú)ARP 協(xié)議支持時(shí)，為了顯示ARP 緩存中的MAC、IP 地址信息，運行arp -a 命令，結果為空，并且其它網(wǎng)絡(luò )應用都不能工作，整個(gè)系統的網(wǎng)絡(luò )部分由于該底層協(xié)議的失效而癱瘓。將ARP 協(xié)議構件用insmod 命令裝入后，網(wǎng)絡(luò )部分恢復正常。

4.2 測試ICMP 協(xié)議構件

在內核不加載ICMP 協(xié)議構件時(shí)，從外界ping 主機，ping 命令顯示超時(shí)，即ping 不通。內核接收及處理傳來(lái)的ICMP 數據包的函數接口找不到相應的功能實(shí)現，不能正常返回確認消息包。在將ICMP 協(xié)議構件用insmod 命令裝入后，處理數據包的函數正確執行，顯示能夠ping 通。響應時(shí)間如表1 所示。

從表1 可以看出，當ICMP 協(xié)議作為模塊被加載后，ping 命令的響應時(shí)間比該協(xié)議編譯進(jìn)內核的長(cháng)，增長(cháng)的幅度為(0.668-0.611)/0.611=0.093 ，性能下降不超過(guò)1%。而且，從內核啟動(dòng)速度來(lái)看，構件化ICMP 協(xié)議的結果，由于構件化的內核在網(wǎng)絡(luò )部分啟動(dòng)過(guò)程中沒(méi)有初始化ICMP 協(xié)議部分，啟動(dòng)速度略有提高。

4.3 測試UDP 協(xié)議構件

為了便于觀(guān)察系統性能的變化，本文采用Linux 網(wǎng)絡(luò )性能測試軟件Netperf 對UDP 協(xié)議構件進(jìn)行測試，主要測試UDP 的批量數據傳輸性能、請求和響應性能。測試結果如表2 所示。

從表2 可以看出，協(xié)議構件化之后的網(wǎng)絡(luò )性能有損失，其數據傳輸性能的下降幅度為(l55.2-140.3)/155.2=0.096 ，請求/響應性能的下降幅度為(620.1-*.9)/620.1=0.025 ，它們都低于一個(gè)數量級。

4.4 測試TCP 協(xié)議構件

在目標板和PC 機之間進(jìn)行測試，PC 機作為客戶(hù)端，目標板作為服務(wù)器，并編寫(xiě)客戶(hù)端和服務(wù)器測試程序。在內核不加載TCP 協(xié)議構件時(shí)，運行客戶(hù)端程序，PC 機提示不能和服務(wù)器連接;加載TCP 協(xié)議構件后，再次運行客戶(hù)端程序，觀(guān)察PC 機，顯示連接成功，在目標板上鍵入字符，在PC 機上可以顯示接收到的字符。

從上面的測試結果可知，對Linux 下的TCP/IP 構件化后，盡管系統性能會(huì )略有損失，但損失不大，用此較小的代價(jià)可以換取升級、維護的成本大大降低、新協(xié)議開(kāi)發(fā)時(shí)間大大縮短，從而說(shuō)明構件化協(xié)議的可行性和優(yōu)越性，在實(shí)際應用中可以認為是一種有效的方法。

5 結論

本文針對嵌入式服務(wù)器的網(wǎng)絡(luò )實(shí)時(shí)通信的應用，將構件技術(shù)引入Linux 的TCP/IP 協(xié)議設計中，提出了一種構件化TCP/IP 協(xié)議棧中主要協(xié)議的方法，并對構件化的協(xié)議進(jìn)行測試，結果表明構件化的協(xié)議可以動(dòng)態(tài)載入實(shí)時(shí)改進(jìn)和裁剪的Linux 系統，不僅減少了嵌入式Linux 內核的尺寸，而且增強了系統網(wǎng)絡(luò )通信協(xié)議設計的靈活性。