前面我們已經完成了LwIP協議棧基於邏輯的基本移植，在這一節我們將以RAW API來實現UDP服務器。
1、UDP協議簡述
UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議一樣用於處理數據包，是一種無連接的協議。在OSI模型中，處於傳輸層，是IP協議的上層協議。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之后，是無法得知其是否安全完整到達的。
UDP協議的主要作用是將網絡數據流量壓縮成數據包的形式。一個典型的數據包就是一個二進制數據的傳輸單位。每一個數據包的前8個字節用來包含報頭信息，剩余字節則用來包含具體的傳輸數據。
UDP報頭由4個域組成，其中每個域各占用2個字節，具體如下：源端口號、目標端口號、數據報長度、校驗值。其數據結構如下：
UDP協議使用端口號為不同的應用保留其各自的數據傳輸通道。UDP和TCP協議正是采用這一機制實現對同一時刻內多項應用同時發送和接收數據的支持。數據發送一方（可以是客戶端或服務器端）將UDP數據包通過源端口發送出去，而數據接收一方則通過目標端口接收數據。有的網絡應用只能使用預先為其預留或注冊的靜態端口；而另外一些網絡應用則可以使用未被注冊的動態端口。因為UDP報頭使用兩個字節存放端口號，所以端口號的有效范圍是從0到65535。一般來說，大於49151的端口號都代表動態端口。
數據報的長度是指包括報頭和數據部分在內的總字節數。因為報頭的長度是固定的，所以該域主要被用來計算可變長度的數據部分。數據報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在內的數據報的最大長度為65535字節。不過，一些實際應用往往會限制數據報的大小，有時會降低到8192字節。
UDP協議使用報頭中的校驗值來保證數據的安全。校驗值首先在數據發送方通過特殊的算法計算得出，在傳遞到接收方之后，還需要再重新計算。如果某個數據報在傳輸過程中被第三方篡改或者由於線路噪音等原因受到損壞，發送和接收方的校驗計算值將不會相符，由此UDP協議可以檢測是否出錯。
2、UDP服務器設計
前面我們簡要的介紹了UDP協議及其數據報，接下來我們將考慮怎么實現基於UDP協議的服務器。
首先，我們來看一看與UDP相關的API函數，並對它們作一個初步的介紹，應為我們需要使用它們來實現我們的應用。函數及說明如下：
了解了這些函數，我們現在考慮其實現過程。對於UDP服務器端來說，實現相對簡潔。其實現步驟如下：
首先，生成一個新的UDP控制塊。
接着，綁定UDP控制塊到任意IP地址及制定端口。
最后，為UDP控制塊注冊數據處理回調函數，這里需要說明一下，這就是RAW AIP的回調函數。根據你要實現的功能不同復雜程度完全不一樣。我們由於要實現一個回環服務器，所以相對簡單。只需要將收到的信息，以我們想要的方式發送回客戶端就可以了。
為了很好的實現UDP服務器，還有一個問題需要設計好，就是我們前面我們曾提到的端口。我們都知道TCP/IP協議族包括有很多的協議，那通訊究竟是針對哪一個協議發生的呢？所謂兩台機器間的通訊，實際上是主機上的應用進程間的通訊，端口號就是為了最終實現主機上應用進程的通訊。我們常見且會在后續使用到的協議端口如下：
為了使用方便我們將這些端口定義為宏，並存儲到一個專門的文件中。在這里我們本次實現UDP服務器也需要制定一個端口，其實支持UDP的端口都沒問題，但為了方便描述我們制定其為回環顯示端口。
3、UDP服務器實現
我們了解了其實現的基本過程，其實並不復雜。事實上，回調函數的內容才是我們真正需要考慮的東西。我們將其實現分為兩個部分：一是UDP服務器的初始化部分；二是UDP服務器功能部分，也就是回調函數所執行的內容。
首先實現UDP服務器的初始化部分。初始化部分定義一個新的UDP控制塊，並將其綁定到任意IP地址及指定端口。然后注冊數據處理回調函數。
1 /* UDP初始化配置 */ 2 void UDP_Server_Initialization(void) 3 { 4 static char * recv_arg="We recieved a UDP data\n"; 5 struct udp_pcb *upcb; 6 7 /* 生成一個新的UDP控制塊 */ 8 upcb = udp_new(); 9 10 /* 綁定upcb塊到任意IP地址及指定端口*/ 11 udp_bind(upcb, IP_ADDR_ANY, UDP_ECHO_SERVER_PORT); 12 13 /* 為upcb指定數據處理回調函數 */ 14 udp_recv(upcb,UDPServerCallback,(void *)recv_arg); 15 }
關於為什么要將本地IP綁定到任意IP呢？這是因為UDP服務器收到數據包后，LwIP會先判斷其數據包的目的IP和端口是否和本地注冊的PCB控制塊綁定的本地的IP和本地端口號是否匹配。所以我們綁定PCB控制塊本地IP設為IP_ADDR_ANY時，只要收到的數據包的目的IP非廣播地址，端口號匹配，那么均認為數據包的目的IP和端口是與本地注冊的PCB控制塊綁定的本地IP和端口號相匹配的。省去了自己構造本地IP的過程。
初始化完畢后，注冊了數據處理回調函數。接下來需要實現回調函數的內容。回調函數主要實現對數據的處理，這取決於自己的需求。在這里我們在接收到UDP客戶端數據包后，不對其作什么處理，因為這一數據本來無意義，我們對任何的客戶端請求給予固定的回復。
1 /* 定義UDP服務器數據處理回調函數 */ 2 static void UDPServerCallback(void *arg,struct udp_pcb *upcb,struct pbuf *revBuf,const ip_addr_t *addr,u16_t port) 3 { 4 struct pbuf *sendBuf = NULL; 5 const char* reply = "This is reply!\n"; 6 7 pbuf_free(revBuf); 8 9 sendBuf = pbuf_alloc(PBUF_TRANSPORT, strlen(reply)+1, PBUF_RAM); 10 if(!sendBuf) 11 { 12 return; 13 } 14 15 memset(sendBuf->payload,0,sendBuf->len); 16 memcpy(sendBuf->payload, reply, strlen(reply)); 17 udp_sendto(upcb, sendBuf, addr, port); 18 pbuf_free(sendBuf); 19 }
對於這個回調函數，它實際是賦給一個函數指針，所以雖然它的內容和名稱可以隨意，但其格式是有要求的：void (*udp_recv_fn)(void *arg, struct udp_pcb *pcb, struct pbuf *p,const ip_addr_t *addr, u16_t port)
4、結論
至此，我們完成了簡單的UDP服務器，在這里我們使用客戶端來測試一下這個UDP服務器，測試結果如下：
這里只測試了一個客戶端兩屆服務器的情況，其實連接多個客戶端的情況也是沒問題的。如下：
佷顯然，如果我們希望實現更復雜的UDP服務器，我們只需要將我們想實現的功能做到回調函數中就可以了。
歡迎關注：
