【正文】 數(shù) 據(jù) 段 17 ICMP 報文 ICMP 報文 圖 3 7 ICMP 協(xié)議函數(shù)關系圖 TCP協(xié)議實現(xiàn) 功能概述 為上層提供面向連接的數(shù)據(jù)傳輸服務。在上層有數(shù)據(jù)傳輸要求時，首先建立 TCP 的連接，建立連接時通過有限自動機以三次握手法完成。 TCP 有限狀態(tài)自動機由函數(shù) tcp_fsm()實現(xiàn)。在連接建立好之后，當上層有數(shù)據(jù)需要發(fā)送時，調(diào)用 TCP 層的數(shù)據(jù)發(fā)送函數(shù)tcp_send()，再 調(diào)用下層的 ip_send()函數(shù)實現(xiàn)發(fā)送。 數(shù)據(jù)的接收由 TCP 接收函數(shù) tcp_recv()與 TCP 連接建立好以后的處理函數(shù) estab()完成。用于建立連接的握手包也由接收函數(shù) tcp_recv()接收，當 tcp_recv()接收到建立連接的握手包后，調(diào)用有限狀態(tài)自動機函數(shù) tcp_fsm()轉(zhuǎn)動有限自動機，并發(fā)相應的確認包；在有限狀態(tài)自動機的狀態(tài)達到 OPEN 后，如果收到用戶的數(shù)據(jù)，則調(diào)用函數(shù) estab()放入用戶接收任務 user_rec_task()的接收緩沖區(qū)，然后喚醒該任務。 由于 TCP 協(xié)議要求 發(fā)送每一個數(shù)據(jù)都必須收到確認后才能肯定數(shù)據(jù)己正確發(fā)到目的地，如果在規(guī)定時間內(nèi)仍未收到確認，則要重發(fā)該數(shù)據(jù)。在本設計中，有一個重傳隊列，當發(fā)送了一個 TCP 數(shù)據(jù)段后，就把該數(shù)據(jù)段放入重傳隊列中，同時設置一個重傳定時事件放入定時事件鏈 TimerEvent_List 上。與此同時，專門由一個定時器任務 timer_task 負責管理該定時事件鏈。如果重傳的規(guī)定時間到達仍未收到確認，則 timer_task()將會根據(jù)定時事件鏈上的定時事件從重傳隊列上取下需重傳的數(shù)據(jù)發(fā)送，并再次放入重傳隊列，重新設置重傳定時時間；如果在規(guī)定 時間內(nèi)，收到確認，則 TCP 數(shù)據(jù)接收函數(shù)將把該數(shù)據(jù)從重傳隊列中取出并把定時事件鏈上的定時事件去掉。 函數(shù) tcp_init()負責 TCP 協(xié)議的初始化，包括任務的創(chuàng)建、數(shù)據(jù)結構的初始化等工作。tcp_init()應用初始化時被函數(shù) _init()調(diào)用。 函數(shù)關系圖 TCP 協(xié)議主要函數(shù)關系如圖 38 所示，虛線框內(nèi)為 TCP 協(xié)議實現(xiàn)。 IP 協(xié)議實現(xiàn) 執(zhí)行 icmp_proc()函數(shù) 執(zhí)行 icmp_send()函數(shù) 18 用戶數(shù)據(jù) 用戶數(shù)據(jù) OPEN 狀態(tài) 非 OPEN 狀態(tài) TCP 數(shù)據(jù)報文 IP 數(shù)據(jù)報文 圖 38 TCP 協(xié)議主要函數(shù)關系圖 UDP協(xié)議實現(xiàn) 功能概述 UDP 協(xié)議建立在 IP 協(xié)議之上，同 IP 協(xié)議一樣提供無連接的數(shù)據(jù)報傳輸。相對 IP 協(xié)議而言，唯一增加的功能是提供協(xié)議端口以實現(xiàn)進程間的通 信。 從理論上看 ,TCP 的可靠性是以許多復雜措施及由此而增加的開銷為代價換來的。 TCP 提供面向鏈接的、可靠的服務 ,而 UDP 是無面向鏈接的。由于 UDP 沒有可靠性的保證機制 ,因此能全速地進行數(shù)據(jù)通信 (即充分發(fā)揮物理通信設備的速度 )。又因為 UDP 沒有點對點接入的要求 ,可以實現(xiàn) “一對多點 ”,“多對多點 ”的廣播和多點播發(fā)信息。 UDP 的不可靠傳輸?shù)娜毕?,可以在使用 UDP 時 ,在應用層增加提高 UDP 可靠性的代碼來彌補。 發(fā)送數(shù)據(jù)時，上層調(diào)用本層的數(shù)據(jù)發(fā)送函數(shù) udp_send()，在 udp_send 中再調(diào)用下層的ip_send()函數(shù)實現(xiàn)發(fā)送。 當下層接收到數(shù)據(jù)時，調(diào)用本層的數(shù)據(jù)接收函數(shù) udp_recv()，在 udp_recv()中通知用戶接收任務有 UDP 數(shù)據(jù)報到達。 函數(shù) udp_init()負責 UDP 協(xié)議的初始化，包括任務的創(chuàng)建、數(shù)據(jù)結構的初始化等工作。udp_init()在應用初始化時被 _ init()調(diào)用。 函數(shù)關系圖 UDP 協(xié)議的函數(shù)關系如圖 39 所示，虛線框中為 UDP 協(xié)議實現(xiàn)。 estab ()函數(shù) 有限狀態(tài)自動機 tcp_fsm() 接收函數(shù) tcp_recv() 發(fā)送 ack 函數(shù) tcp_ack() 檢查 ack 域函數(shù) ackcheck() 發(fā)送函數(shù) tcp_send() 窗口探測函數(shù) winprobe() 19 用戶數(shù)據(jù) 用戶數(shù) 據(jù) UDP 數(shù)據(jù)報文 UDP 數(shù)據(jù)報文 圖 39 UDP 函數(shù)關系圖 udp_recv()函數(shù) udp_send()函數(shù) 20 4 嵌入式 TCP/IP 協(xié)議研究設計 地址解析協(xié)議 ARP 詳細設計 概述 ARP 效率 :在每臺使用 ARP 的主機中，都保留了一個專用的內(nèi)存區(qū) (即高速緩存 )，存放最近獲得的網(wǎng)間網(wǎng) 物理地址編聯(lián)。一收到 ARP 應答，主機就將信宿機的網(wǎng)間網(wǎng)地址和物理地址存入緩存。欲發(fā)送報文 時，首先去緩存中查相應編聯(lián)，若找不到，再利用 ARP進行地址解析。實驗表明，由于多數(shù)網(wǎng)絡通訊都需要持續(xù)發(fā)送多個報文，所以高速緩存大大提高了 ARP 的效率。 ARP 改進：為進一步提高效率， ARP 還采取了以下措施： ARP 請求報文中放入信源機的網(wǎng)間網(wǎng)地址 物理地址編聯(lián)，以防止信源機緊接著為解析信源機的物理地址而再來一次動態(tài)解析； ，網(wǎng)上所有主機都可以將它存入自己的高速緩存。 ，令其主動廣播自己的地址編聯(lián)，以免其它主機對它運行 ARP。 函數(shù)詳細設計 (1) arp_init(接口函數(shù)，可被上層調(diào)用 ) 實現(xiàn)對 ARP 數(shù)據(jù)報文結構的初始化及對 ARP 映射表的初始化。 設計流程如圖 41 所示： 21 圖 41 ARP 初始化流程圖 (2) arp_req(接口函數(shù)，可被上層調(diào)用 ) 發(fā) ARP 請求報文，要求解析對方的物理地址 (不等待響應 )。 設計流程如圖 42 所示。 開 始 以太網(wǎng)幀頭的初始化： copydata(,6)； copydata(,6)； =sizeof(arp)14； 硬件類型初始化 協(xié)議類型初始化 地址長度的初始化： =EADDR_LEN； =IPLEN； ARP 操作碼的初始化： =ARP_ REQUEST； 源硬件地址初始化； 源 IP 地址初始化； 目的硬件地址初始 化； 目的 IP 地址初始化； ARP 映射表的初始化： For(I=1； IArp_MaxItem。I++) arptable[I].item_state=FREE； 結 束 22 圖 42 發(fā)送 ARP 請求報文流程圖 (3) 發(fā)送 ARP 應答報文，設計流程如圖 43 所示 (定義一局部變量 struct arpkt arp；定義一中間變量 unsigned char * data 用于交換數(shù)據(jù)時轉(zhuǎn)移數(shù)據(jù) ) 。 圖 43 發(fā)送 ARP 應答報文流程圖 (4) arp_pro(接口函數(shù)，被上層調(diào)用 ) 對輸入的 ARP 報文進行分析，判斷是否為請求報文或者為應答報文。若為請求報文，發(fā)回響應；若為響應報文，將等待隊列 上等待解析該物理地址的 IP 數(shù)據(jù)報依次發(fā)送出去。 算法設計流程如圖 44 所示。 開 始 給定參數(shù)，為存放 ARP 報文中請一緩沖區(qū) 根據(jù)參數(shù)填寫 ARP 報文 發(fā)送 ARP 請求報文 ne_transmit(dev,(unsigned char *)arp)； 設置定時器事件 return (SUCCEED)； 開 始 交換源和目的域為發(fā)送響應做準備 發(fā)送 ARP 應答報文 ne_transmit(dev,(unsigned char *)arp)； 返回成功信息 :return (SUCCEED)； 23 圖 44 ARP 報文處理算法流程 (5) cacheupdate 更新 ARP 映射表的相應表項。 (6) cachelook(接口函數(shù)，被上層調(diào)用 ) 對 ARP 映射表進行查找，若找到相應的表項，則返回該表項的代碼號，否則返回空指針。 (7) pend_ipkt(接口函數(shù)，被上層調(diào)用 ) 把為解析信宿物理地址的 IP 數(shù)據(jù)報掛到相應的等待隊列中。 (8) arp_qsend 獲得物理地址后，將等待隊列鏈表中的 IP 數(shù) 據(jù)報發(fā)送出去。 24 網(wǎng)際協(xié)議 IP 協(xié)議詳細設計 概述 協(xié)議標準規(guī)定，任何實現(xiàn) IP 的程序都必須能夠?qū)?shù)據(jù)報分片及重組。事實上，由于嵌入式系統(tǒng)生成的數(shù)據(jù)報足夠小，能夠直接通過網(wǎng)絡傳輸，因此，嵌入式系統(tǒng)并不需要將輸出數(shù)據(jù)報進行分片。但是嵌入式系統(tǒng)有可能接收到分片的數(shù)據(jù)報，因此嵌入式 TCP/IP 必須具有負責重組的程序代碼，否則，它就不能與互聯(lián)網(wǎng)上所有的計算機通信。為了簡化代碼，提高效率，本設計不對輸出數(shù)據(jù)報進行分片，只實現(xiàn)了對輸入數(shù)據(jù)報片的重組。 重組數(shù)據(jù)報時， IP 協(xié)議在能夠成功地重組完整的數(shù)據(jù)報 之前，不斷積累輸入的數(shù)據(jù)報片。一旦重組成功， IP 將其送給上層協(xié)議，或者繼續(xù)路由。由于 IP 并不保證順序投遞，因此要求 IP 能夠接收順序混亂的或延遲的數(shù)據(jù)報片。 函數(shù)設計實現(xiàn) (1) ip_route(unsigned char*packet, unsigned short length, unsigned char source[4], unsigned char dest[4]) ； 參數(shù)說明 :packet??需路由的數(shù)據(jù)報首指針； length??需路由的數(shù)據(jù) 報長度； source??需路由的數(shù)據(jù)報源地址； dest??需路由的數(shù)據(jù)報的目的地址； 分片表 圖 45 數(shù)據(jù)報分片重組數(shù)據(jù)結構 函數(shù)功能說明 :以輸入?yún)?shù)中的目的 IP 地址為索引，查找路由表。 若找到相應路由表項，則按照路由表項所示調(diào)用函數(shù) ip_send()；若沒有找到相應路由表項，則丟失該報文。算法流程圖如圖 46 所示。 找到路由 沒有該路由 圖 46 IP 路由算法流程圖 0 1 2 3 分片指針 0 分片指針 1 分片指針 9 Buffer Buffer Buffer Buffer 開 始 取輸入數(shù)據(jù)報文的目的 IP 地址 以該 IP 地址為索引查找路由表 是否有該路由 丟棄該報文 出錯返回 得到該路由的下一個網(wǎng)關 IP地址及發(fā)送的網(wǎng)絡接口 調(diào)用函數(shù) ip_send () 25 (2) ip_recv(unsigned char*ipp， unsigned short length)； 參數(shù)說明 ： ipp??接收的 1P 數(shù)據(jù)報首指針； length??接收的 IP 數(shù)據(jù)報長度； 函數(shù)功能說明 :首先調(diào)用函數(shù) ip_hdrcheck()檢查輸入 IP 數(shù)據(jù)報的頭標校驗和。若檢查未通過，則丟