曹欲曉,韓 磊
(南京工程學(xué)院 計算機工程學(xué)院,江蘇 南京 211167)
隨著嵌入式技術(shù)、網(wǎng)絡(luò)技術(shù)的發(fā)展,實現(xiàn)網(wǎng)絡(luò)互聯(lián)已經(jīng)成為嵌入式系統(tǒng)發(fā)展的一個必然趨勢。在目前的技術(shù)條件下,越來越多的嵌入式系統(tǒng)選擇了TCP/IP作為與其他計算機系統(tǒng)互聯(lián)的網(wǎng)絡(luò)協(xié)議。嵌入式TCP/IP協(xié)議棧已經(jīng)成為嵌入式系統(tǒng)研究與應(yīng)用中的一個重要領(lǐng)域。
由于嵌入式系統(tǒng)的軟硬件資源都較為有限,大多數(shù)嵌入式系統(tǒng)中運行的TCP/IP協(xié)議棧均根據(jù)嵌入式系統(tǒng)的特點進行了相應(yīng)的裁剪。目前應(yīng)用比較廣泛的嵌入式TCP/IP 協(xié) 議 棧 有 :ucTCP-IP、LWIP、uIP、Linux TCP/IP等。其中uIP是專為8 bit和16 bit的嵌入式微控制器設(shè)計的微型TCP/IP協(xié)議棧,它具有良好的互操作性,并遵循RFC標(biāo)準(zhǔn)。uIP協(xié)議棧的特點是具有很小的代碼量,運行時需要的內(nèi)存很少,實現(xiàn)了常用的TCP/IP協(xié)議;代碼注釋詳盡,可以用于商業(yè)或非商業(yè)用途[1]。由于具有上述特點,uIP被廣泛應(yīng)用在嵌入式系統(tǒng)的網(wǎng)絡(luò)互聯(lián)中。
在使用uIP的嵌入式系統(tǒng)的軟件體系結(jié)構(gòu)中,uIP協(xié)議棧相當(dāng)于一個代碼庫,它通過一系列的函數(shù)實現(xiàn)與底層硬件和上層應(yīng)用程序的通信。uIP協(xié)議棧與系統(tǒng)底層和上層應(yīng)用之間的關(guān)系如圖1所示[2]。
圖1 uIP協(xié)議棧體系結(jié)構(gòu)
從圖 1可以看出,uIP協(xié)議棧主要提供了uip_input()和uip_periodic()2個函數(shù)供系統(tǒng)底層調(diào)用。uIP協(xié)議棧與應(yīng)用程序的主要接口是UIP_APPCALL()和UIP_UDP_APPCALL()。
uIP初始化時調(diào)用uip_init()函數(shù),它的主要功能是初始化協(xié)議棧的監(jiān)聽端口,并把所有連接設(shè)置為關(guān)閉狀態(tài)。當(dāng)網(wǎng)絡(luò)控制芯片驅(qū)動程序接收到一個數(shù)據(jù)包時,驅(qū)動程序?qū)?shù)據(jù)包放入全局緩沖區(qū)uip_buf中,同時把包的大小賦給全局變量uip_len。然后uIP的主控部分調(diào)用uip_input()函數(shù),該函數(shù)將會根據(jù)數(shù)據(jù)包首部的協(xié)議標(biāo)識處理這個包,并在需要時調(diào)用上層應(yīng)用程序。當(dāng)uip_input()返回時,一個輸出數(shù)據(jù)包被放在同一個全局緩沖區(qū)uip_buf中,其大小賦給uip_len。如果uip_len是0,則說明沒有包要發(fā)送,否則主控部分調(diào)用底層系統(tǒng)的發(fā)包函數(shù)將數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)上[3]。
uIP周期計時用于驅(qū)動所有的uIP內(nèi)部時鐘事件。當(dāng)周期計時激發(fā)后,每一個TCP連接都會調(diào)用uIP函數(shù)uip_periodic()。 類似于 uip_input()函數(shù),uip_periodic()函數(shù)返回時,輸出的IP包要放到uip_buf中,供底層系統(tǒng)查詢uip_len的大小以決定是否發(fā)送。
由于使用TCP/IP的應(yīng)用很多,因此應(yīng)用程序作為單獨的模塊由用戶實現(xiàn)。uIP提供一系列接口供用戶程序調(diào)用,其中大部分接口是作為C的宏命令出現(xiàn)的,之所以這樣做主要是考慮到速度、代碼大小、效率和堆棧的使用。用戶需要把對網(wǎng)絡(luò)數(shù)據(jù)包的處理函數(shù)作為接口提供給uIP,并將這個函數(shù)定義為宏UIP_APPCALL()或者 UIP_UDP_APPCALL()。UIP_APPCALL()是用戶對 TCP數(shù)據(jù)包的處理,UIP_UDP_APPCALL()是用戶對 UDP數(shù)據(jù)包的處理[4]。這樣,uIP在接收到底層傳來的數(shù)據(jù)包后,在需要送到上層應(yīng)用程序處理的地方,直接調(diào)用UIP_APPCALL()或者 UIP_UDP_APPCALL()即可,無需修改uIP。
當(dāng)uIP接收到一個UDP數(shù)據(jù)包后,首先從包頭中取出數(shù)據(jù)的長度,然后重新對包進行校驗,如果校驗和不對,則直接丟掉這個包。如果校驗無誤,則對收到的包進行解復(fù)用。此時進行如下判斷:
上述代碼中用到的主要變量、數(shù)據(jù)結(jié)構(gòu)和函數(shù)的含義是:
在uIP的實現(xiàn)中,如果以上判斷語句為真,則對接收到的數(shù)據(jù)包進行處理,處理過程包括調(diào)用用戶上層處理程序 UIP_UDP_APPCALL()、構(gòu)造新包的包頭、計算新包的校驗和等,然后將構(gòu)造好的返回UDP包送到IP層進行處理。
通過對uIP中UDP協(xié)議實現(xiàn)過程的分析可以發(fā)現(xiàn),uIP沒有提供初始化指定端口的函數(shù),僅提供了一個對給定IP地址上給定端口建立UDP連接的函數(shù),其原型是struct uip_udp_conn*uip_udp_new(uip_ipaddr_t*ripaddr,u16_t rport)。由于作為服務(wù)端運行時必須指定監(jiān)聽端口[5],而 uIP沒有提供此功能,因此要讓uIP作為服務(wù)端運行,必須對uIP進行改進。
UDP協(xié)議作為服務(wù)端運行時,同TCP一樣,必須在某個指定端口上監(jiān)聽客戶端是否有數(shù)據(jù)包發(fā)送,如果有則還要接收數(shù)據(jù)包,這就要求在uIP記錄UDP連接的數(shù)據(jù)結(jié)構(gòu)uip_udp_conn中設(shè)置本地端口號一項,具體實現(xiàn)步驟如圖2所示。
圖2 UDP服務(wù)端口初始化
uip_process函數(shù)接收到網(wǎng)絡(luò)控制芯片驅(qū)動程序送來的數(shù)據(jù)包后,當(dāng)判斷出收到的包是UDP包,執(zhí)行2.1中的判斷并且得到結(jié)果為真后,但還需要再做以下工作:如果uip_udp_conn中的目的端口號為0,則說明這是一個來自客戶端的首次與服務(wù)端進行通信的數(shù)據(jù)包,服務(wù)端尚不知道此客戶端的源端口,因此要把uip_udp_conn中的目的端口號設(shè)為收到的包中的源端口號,把uip_udp_conn中的目的IP地址設(shè)為收到的包中的源IP地址,具體代碼如下:
UDP服務(wù)端的端口應(yīng)該可以為來自多個客戶端的請求提供服務(wù),而UDP本身是一種無連接的傳輸層協(xié)議,因此在每次uIP作為服務(wù)端的UDP通信結(jié)束之后,還要釋放uip_udp_conn中記錄的目的端口號,以便下次接收來自不同IP、不同端口的新請求,否則當(dāng)來自其他端口的請求到達(dá)時,uIP會不予響應(yīng)。
在uIP的官方網(wǎng)站上下載到uIP 1.0的源代碼之后,按照本文給出的幾個步驟對uIP 1.0進行改造之后,利用gcc編譯器把uIP 1.0編譯成S3C2410上的可執(zhí)行代碼,把基于S3C2410的開發(fā)板作為UDP服務(wù)器,運行Windows XP的PC機作為客戶端,兩者通過一條交叉網(wǎng)線相聯(lián),在PC機上的測試程序發(fā)出UDP請求后,運行在S3C2410上的uIP可以對PC通過UDP協(xié)議發(fā)出的數(shù)據(jù)進行處理,并給PC作出正確的回復(fù)。實驗證明,通過對uIP進行本文所述的改進之后,uIP具有了作為UDP服務(wù)端的能力。
[1]http://www.sics.se/~adam/uip/index.php/Main_Page.
[2]ADAM D.The uIP embedded TCP/IP stack the uIP 1.0 reference manual.June 2006.
[3]ADAM D.Full TCP/IP for 8-bit architectures[C].In Proceedings of the First International Conference on Mobile Applications,Systems and Services(MOBISYS 2003), San Francisco, May 2003.
[4]ADAM D, OLIVER S, THIEMO V, et al.Protothreads:simplifying event-driven programming of memory-constrained embedded systems[C].In Proceedings of the Fourth ACM Conference on Embedded Networked Sensor Systems(SenSys 2006), Boulder, Colorado, USA, November 2006.
[5]FOROUZAN B A,F(xiàn)EGAN S C著.TCP/ZP協(xié)議簇 [M].謝希仁等,譯.北京:清華大學(xué)出版社,2006.