摘  要： uIP作為一種廣泛使用的輕量級(jí)嵌入式TCP/IP協(xié)議棧，其UDP協(xié)議的實(shí)現(xiàn)還不夠完善，目前最新的1.0版本中僅實(shí)現(xiàn)了UDP客戶端，尚沒(méi)有實(shí)現(xiàn)UDP服務(wù)端。為此，對(duì)其進(jìn)行了以下三方面的改進(jìn)：UDP服務(wù)端口的初始化；接收到UDP客戶端數(shù)據(jù)包后的端口號(hào)判斷及匹配；UDP服務(wù)端發(fā)送報(bào)文后目的端口的釋放。經(jīng)過(guò)以上改進(jìn)后，實(shí)驗(yàn)證明，uIP 1.0中的UDP實(shí)現(xiàn)了服務(wù)端的功能。
關(guān)鍵詞： uIP；嵌入式TCP/IP協(xié)議棧；UDP；端口

    隨著嵌入式技術(shù)、網(wǎng)絡(luò)技術(shù)的發(fā)展，實(shí)現(xiàn)網(wǎng)絡(luò)互聯(lián)已經(jīng)成為嵌入式系統(tǒng)發(fā)展的一個(gè)必然趨勢(shì)。在目前的技術(shù)條件下，越來(lái)越多的嵌入式系統(tǒng)選擇了TCP/IP作為與其他計(jì)算機(jī)系統(tǒng)互聯(lián)的網(wǎng)絡(luò)協(xié)議。嵌入式TCP/IP協(xié)議棧已經(jīng)成為嵌入式系統(tǒng)研究與應(yīng)用中的一個(gè)重要領(lǐng)域。
    由于嵌入式系統(tǒng)的軟硬件資源都較為有限，大多數(shù)嵌入式系統(tǒng)中運(yùn)行的TCP/IP協(xié)議棧均根據(jù)嵌入式系統(tǒng)的特點(diǎn)進(jìn)行了相應(yīng)的裁剪。目前應(yīng)用比較廣泛的嵌入式TCP/IP協(xié)議棧有：ucTCP-IP、LWIP、uIP、Linux TCP/IP等。其中uIP是專為8 bit和16 bit的嵌入式微控制器設(shè)計(jì)的微型TCP/IP協(xié)議棧， 它具有良好的互操作性， 并遵循RFC標(biāo)準(zhǔn)。uIP協(xié)議棧的特點(diǎn)是具有很小的代碼量，運(yùn)行時(shí)需要的內(nèi)存很少，實(shí)現(xiàn)了常用的TCP/IP協(xié)議；代碼注釋詳盡，可以用于商業(yè)或非商業(yè)用途[1]。由于具有上述特點(diǎn)，uIP被廣泛應(yīng)用在嵌入式系統(tǒng)的網(wǎng)絡(luò)互聯(lián)中。
1 uIP協(xié)議棧的體系結(jié)構(gòu)
    在使用uIP的嵌入式系統(tǒng)的軟件體系結(jié)構(gòu)中，uIP協(xié)議棧相當(dāng)于一個(gè)代碼庫(kù)，它通過(guò)一系列的函數(shù)實(shí)現(xiàn)與底層硬件和上層應(yīng)用程序的通信。uIP協(xié)議棧與系統(tǒng)底層和上層應(yīng)用之間的關(guān)系如圖1所示[2]。

    從圖1可以看出，uIP協(xié)議棧主要提供了uip_input()和uip_periodic()2個(gè)函數(shù)供系統(tǒng)底層調(diào)用。uIP協(xié)議棧與應(yīng)用程序的主要接口是UIP_APPCALL()和UIP_UDP_APPCALL()。

    uIP初始化時(shí)調(diào)用uip_init()函數(shù)，它的主要功能是初始化協(xié)議棧的監(jiān)聽(tīng)端口，并把所有連接設(shè)置為關(guān)閉狀態(tài)。當(dāng)網(wǎng)絡(luò)控制芯片驅(qū)動(dòng)程序接收到一個(gè)數(shù)據(jù)包時(shí)，驅(qū)動(dòng)程序?qū)?shù)據(jù)包放入全局緩沖區(qū)uip_buf中，同時(shí)把包的大小賦給全局變量uip_len。然后uIP的主控部分調(diào)用uip_input()函數(shù)，該函數(shù)將會(huì)根據(jù)數(shù)據(jù)包首部的協(xié)議標(biāo)識(shí)處理這個(gè)包，并在需要時(shí)調(diào)用上層應(yīng)用程序。當(dāng)uip_input()返回時(shí)，一個(gè)輸出數(shù)據(jù)包被放在同一個(gè)全局緩沖區(qū)uip_buf中，其大小賦給uip_len。如果uip_len是0，則說(shuō)明沒(méi)有包要發(fā)送，否則主控部分調(diào)用底層系統(tǒng)的發(fā)包函數(shù)將數(shù)據(jù)包發(fā)送到網(wǎng)絡(luò)上[3]。

    uIP周期計(jì)時(shí)用于驅(qū)動(dòng)所有的uIP內(nèi)部時(shí)鐘事件。當(dāng)周期計(jì)時(shí)激發(fā)后，每一個(gè)TCP連接都會(huì)調(diào)用uIP函數(shù)uip_periodic()。類似于uip_input()函數(shù)，uip_periodic()函數(shù)返回時(shí)，輸出的IP包要放到uip_buf中，供底層系統(tǒng)查詢uip_len的大小以決定是否發(fā)送。
    由于使用TCP/IP的應(yīng)用很多，因此應(yīng)用程序作為單獨(dú)的模塊由用戶實(shí)現(xiàn)。uIP提供一系列接口供用戶程序調(diào)用，其中大部分接口是作為C的宏命令出現(xiàn)的，之所以這樣做主要是考慮到速度、代碼大小、效率和堆棧的使用。用戶需要把對(duì)網(wǎng)絡(luò)數(shù)據(jù)包的處理函數(shù)作為接口提供給uIP，并將這個(gè)函數(shù)定義為宏UIP_APPCALL()或者UIP_UDP_APPCALL()。UIP_APPCALL()是用戶對(duì)TCP數(shù)據(jù)包的處理，UIP_UDP_APPCALL()是用戶對(duì)UDP數(shù)據(jù)包的處理[4]。這樣，uIP在接收到底層傳來(lái)的數(shù)據(jù)包后，在需要送到上層應(yīng)用程序處理的地方，直接調(diào)用UIP_APPCALL()或者UIP_UDP_APPCALL()即可，無(wú)需修改uIP。
2 uIP的UDP協(xié)議分析
2.1 UDP協(xié)議的實(shí)現(xiàn)
    當(dāng)uIP接收到一個(gè)UDP數(shù)據(jù)包后，首先從包頭中取出數(shù)據(jù)的長(zhǎng)度，然后重新對(duì)包進(jìn)行校驗(yàn)，如果校驗(yàn)和不對(duì)，則直接丟掉這個(gè)包。如果校驗(yàn)無(wú)誤，則對(duì)收到的包進(jìn)行解復(fù)用。此時(shí)進(jìn)行如下判斷：
if(uip_udp_conn->lport != 0 &&
  UDPBUF->destport == uip_udp_conn->lport &&
  (uip_udp_conn->rport == 0 ||
  UDPBUF->srcport == uip_udp_conn->rport) &&
  (uip_ipaddr_cmp(uip_udp_conn->ripaddr， all_zeroes_addr) ||
uip_ipaddr_cmp(uip_udp_conn->ripaddr， all_ones_addr) ||      uip_ipaddr_cmp(BUF->srcipaddr， uip_udp_conn->ripaddr)))          上述代碼中用到的主要變量、數(shù)據(jù)結(jié)構(gòu)和函數(shù)的含義是：
uip_udp_conn->lport：本地UDP的源端口；
uip_udp_conn->rport：本地UDP的目的端口；
UDPBUF->srcport：接收到的數(shù)據(jù)包中的源端口；
UDPBUF->destport：接收到的數(shù)據(jù)包中的目的端口；
uip_udp_conn->ripaddr：本地UDP的目的IP地址；
BUF->srcipaddr：接收到的數(shù)據(jù)包中的源IP地址；
all_zeroes_addr：IP地址0.0.0.0；
all_ones_addr：IP地址255.255.255.255；
    uip_ipaddr_cmp：IP地址比較函數(shù)，如果參加比較的兩個(gè)IP地址相等，則返回1。
    在uIP的實(shí)現(xiàn)中，如果以上判斷語(yǔ)句為真，則對(duì)接收到的數(shù)據(jù)包進(jìn)行處理，處理過(guò)程包括調(diào)用用戶上層處理程序UIP_UDP_APPCALL()、構(gòu)造新包的包頭、計(jì)算新包的校驗(yàn)和等，然后將構(gòu)造好的返回UDP包送到IP層進(jìn)行處理。
2.2 UDP實(shí)現(xiàn)的不足
    通過(guò)對(duì)uIP中UDP協(xié)議實(shí)現(xiàn)過(guò)程的分析可以發(fā)現(xiàn)，uIP沒(méi)有提供初始化指定端口的函數(shù)，僅提供了一個(gè)對(duì)給定IP地址上給定端口建立UDP連接的函數(shù)，其原型是struct uip_udp_conn*uip_udp_new(uip_ipaddr_t*ripaddr，u16_t rport)。由于作為服務(wù)端運(yùn)行時(shí)必須指定監(jiān)聽(tīng)端口[5]，而uIP沒(méi)有提供此功能，因此要讓uIP作為服務(wù)端運(yùn)行，必須對(duì)uIP進(jìn)行改進(jìn)。
3 uIP中UDP協(xié)議的改進(jìn)
3.1 增加初始化UDP服務(wù)端口
    UDP協(xié)議作為服務(wù)端運(yùn)行時(shí)，同TCP一樣，必須在某個(gè)指定端口上監(jiān)聽(tīng)客戶端是否有數(shù)據(jù)包發(fā)送，如果有則還要接收數(shù)據(jù)包，這就要求在uIP記錄UDP連接的數(shù)據(jù)結(jié)構(gòu)uip_udp_conn中設(shè)置本地端口號(hào)一項(xiàng)，具體實(shí)現(xiàn)步驟如圖2所示。

3.2 IP地址、端口號(hào)的判斷及匹配
    uip_process函數(shù)接收到網(wǎng)絡(luò)控制芯片驅(qū)動(dòng)程序送來(lái)的數(shù)據(jù)包后，當(dāng)判斷出收到的包是UDP包，執(zhí)行2.1中的判斷并且得到結(jié)果為真后，但還需要再做以下工作：如果uip_udp_conn中的目的端口號(hào)為0，則說(shuō)明這是一個(gè)來(lái)自客戶端的首次與服務(wù)端進(jìn)行通信的數(shù)據(jù)包，服務(wù)端尚不知道此客戶端的源端口，因此要把uip_udp_conn中的目的端口號(hào)設(shè)為收到的包中的源端口號(hào)，把uip_udp_conn中的目的IP地址設(shè)為收到的包中的源IP地址，具體代碼如下：
if(uip_udp_conn->rport==0)
{
    uip_udp_conn->rport=UDPBUF->srcport；                memcpy(uip_udp_conn->ripaddr，UDPBUF->srcipaddr，sizeof(uip_ipaddr_t ))；
}
3.3 UDP服務(wù)端目的端口的釋放
    UDP服務(wù)端的端口應(yīng)該可以為來(lái)自多個(gè)客戶端的請(qǐng)求提供服務(wù)，而UDP本身是一種無(wú)連接的傳輸層協(xié)議，因此在每次uIP作為服務(wù)端的UDP通信結(jié)束之后，還要釋放uip_udp_conn中記錄的目的端口號(hào)，以便下次接收來(lái)自不同IP、不同端口的新請(qǐng)求，否則當(dāng)來(lái)自其他端口的請(qǐng)求到達(dá)時(shí)，uIP會(huì)不予響應(yīng)。
    在uIP的官方網(wǎng)站上下載到uIP 1.0的源代碼之后，按照本文給出的幾個(gè)步驟對(duì)uIP 1.0進(jìn)行改造之后，利用gcc編譯器把uIP 1.0編譯成S3C2410上的可執(zhí)行代碼，把基于S3C2410的開(kāi)發(fā)板作為UDP服務(wù)器，運(yùn)行Windows XP的PC機(jī)作為客戶端，兩者通過(guò)一條交叉網(wǎng)線相聯(lián)，在PC機(jī)上的測(cè)試程序發(fā)出UDP請(qǐng)求后，運(yùn)行在S3C2410上的uIP可以對(duì)PC通過(guò)UDP協(xié)議發(fā)出的數(shù)據(jù)進(jìn)行處理，并給PC作出正確的回復(fù)。實(shí)驗(yàn)證明，通過(guò)對(duì)uIP進(jìn)行本文所述的改進(jìn)之后，uIP具有了作為UDP服務(wù)端的能力。
參考文獻(xiàn)
[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， FEGAN S C著. TCP/ZP協(xié)議簇[M]. 謝希仁等，譯.北京：清華大學(xué)出版社，2006.