W5100E01-AVR(W5100評估板用戶手冊)(五)

W5100E01-AVR是為AVR開發者提供的W5100評估板。本文是W5100E01-AVR的用戶手冊,希望對大家有所幫助。今天我們接着昨天的博文繼續介紹:

第一部分在這裡:W5100E01-AVR是什麼?怎麼用?(用戶手冊V1.0版)

W5100E01-AVR(W5100評估板用戶手冊)(一)

第二部分在這裡:W5100E01-AVR是什麼?怎麼用?(二)(用戶手冊V1.0版)

W5100E01-AVR(W5100評估板用戶手冊)(二)

第三部分在這裡:W5100E01-AVR是什麼?怎麼用?(三)(用戶手冊V1.0版)

W5100E01-AVR(W5100評估板用戶手冊)(三)

第四部分在這裡:W5100E01-AVR是什麼?怎麼用?(四)(用戶手冊V1.0版)

W5100E01-AVR(W5100評估板用戶手冊)(四)

 

3.2.6.3. Loopback UDP

Loopback UPD程序是一個使用UDP協議的單播數據包通信的程序,操作流程與Loopback TCP客戶/服務器相同。UDP通信包括單播數包通信和廣播數據包通信,並且基本上支持使用單一信道與多目的地址通信的一對多通信方式。

Loopback UDP程序使用Loopback _udp()函數,Loopback _udp()函數的流程圖如<圖3 -16>所示。

當處於in SOCK_CLOSED狀態下,使用SOCK_DGRAM、端口號和選項標誌位作為參數創建UDPsocket調用socket(),

與TCP通信正好相反,UDP數據通信是一個沒有要求連接過程的通信。因此,當創建socket後,可以直接進行數據通信。創建UDPsocket後,UDP socket的狀態會從SOCK_CLOSED變成SOCK_UDP。

這裡,UDP使用sendto()函數和recvfrom()函數,而不像TCP數據通信使用send() 函數and recv()函數。

這是因為TCP是確定目的地址的一對一通信,而UDP是沒有連接程序的一對多通信。sendto()函數將數據作為一個參數發送給特定地址的特定端口,recvfrom()函數則從臨時的端口接收傳來的數據。recvfrom()函數通知用戶使用作為參數發送的destip和destport來接收目的地址的信息。

在Loopback _udp()函數中,沒有使用close()函數的例子,但是如果我們不再需要UDP通信,通常也可以調用close()函數關閉UDP socket。

3.2.6.4. Web服務

Web服務器程序是使用運行在TCP協議上的HTTP協議的TCP服務器程序。在建立Web服務器程序之前,我們需要了解在Web服務器和Web客戶(瀏覽器)之間傳輸消息的HTTP協議消息結構。

HTTP(超文本傳輸協議)是因特網中在Web服務器和客戶瀏覽器之間傳輸數據使用的協議。

Web服務器程序分析函數和從瀏覽器接收到的HTTP請求消息的URI(統一資源標示符)。如果相關的URI只是單純的頁面請求,這個頁面會發送。如果URI請求一個行為,例如CGI(公共網關接口),它會採取行動並將結果顯示在頁面中。

<圖3.17>所示為web服務器和web客戶端之間的HTTP信息流,<表3-28>所示為HTTP信息結構。

想了解更多關於HTTP的信息,請參考RFC2616。HTTP請求信息根據瀏覽器類型的不同而改變,<表3-29>所示為Windows 2000的瀏覽器和評估板上的HTTP信息通信的例子。

Web服務器程序由管理HTTP服務器socket的of web_server()函數和管理HTTP信息的函數組成。

<圖3.18>所示為web_server()函數流程圖。

因為web_server()是TCP服務器程序,所以它的創建跟3.2.6.1講的Loopback _tcps()函數類似,web_server()和Loopback _tcps()不同的地方在於數據通信代碼。web_server()函數調用從處於SOCK_ESTABLISHED狀態下的http socket的HTTP請求的proc_http()函數。

在調用proc_http()函數後,web_server()等待從網頁的HTTP請求的HTTP響應消息,再調用disconnect()函數關閉http socket。
這個socket的關閉稱為主動關閉,這種情況下,評估板首先請求客戶關閉。供您參見,被動關閉是可壞蛋首先發起斷開請求。Web服務器支持主動關閉的原因是評估板支持服務器與其他客戶端進行連接。

<圖3‑19: proc_http()函數>

proc_http()函數調用parse_http_request()函數分析從瀏覽器接收的HTTP請求消息。如果分析的HTTP請求是”GET”、”HEAD或”POST”方法,就調用get_http_uri_name()函數,並從HTTP請求消息中提取URI名稱。如果URI名稱為”/”,用評估板的Web服務器的默認頁面”index.html”代替”/”,因為這表示瀏覽器請求的是Web服務器的默認頁面。
通過調用find_http_uri_type()函數得到HTTP請求消息的HTTP請求類型後,如果HTTP請求類型是”CGI”,它就會執行相應的CGI指令的流程。
處理完CGI命令或當HTTP請求不是CGI類型時,就通過URI名稱搜索從評估板創建的ROM文件鏡像。
如果檢索到文件,就創建HTTP響應消息並發送。
HTTP響應消息包括HTTP響應首部傳輸和HTTP響應實體傳輸。對於HTTP響應首部傳輸,它使用HTTP請求類型作為參數調用make_http_response_head()函數去創建HTTP響應首部。傳輸完創建HTTP響應首部後,就開始傳輸HTTP響應實體。例如,如果HTTP響應實體是ROM文件鏡像中的任意文件,這個文件就比W5100的MTU(最大傳輸單元)大很多。因此,在傳輸之前,必須以W5100的最大值為基準將它分割。在這點上,如果在評估板中定義的系統環境變量在HTTP響應實體中存在,就調用replace_sys_env_value()函數,並用評估板中存儲的系統環境變量值取代原有的。

<表3-30>是評估板的ROM文件鏡像“evbctrl.html”的一部分。

評估板的系統環境變量的長度變化是根據系統環境變量值來確定並代替它,例如,假設EVB的源IP地址用字符串表示,那麼最大長度就是16,因此,$SRC_IP_ADDRESS$的長度也是16。我們可以使用WIZnet公司提供的”ROM File Maker.exe”創建評估板的ROM文件系統,想了解更多,請參考”ROM File Maker 手冊 Vx.x.pdf”。

HTTP請求消息可以分為方法和請求地址,後者由parse_http_request()函數解析並保存在’st_http_request’數據類型中,具體定義如<表3-31>,通過get_http_uri_type()函數得到相應的URI類型。

請求地址保存在st_http_request的URI [MAX_URI_SIZE]中,URI名稱在”?”符號之前,查詢字符串在”?”符號之後。當請求地址從Web瀏覽器轉變為Web服務器時,空格字符轉換成’+’的形式,剩下其它的文本轉換成”%HEXHEX”的形式。因此,請求地址的字符需要解碼為原先的值,從’+’到空格,從十六進制轉換成相關的ASCII碼值,具體Request-URI的編碼信息參見RFC1738。請求地址的URI名稱通過get_http_uri_name()函數得到,請求地址的查詢字符串可以包含一個或者更多的”variable=value”對,以”&”作為分隔符。通過get_http_param_value()函數,請求地址可以在查詢字符串中取得期望的值。

評估板的Web服務器圖像處理與傳統Web服務器程序處理程序有所不同,傳統的Web服務器程序處理程序是基於操作系統的,通過分離獨立的行進程間的通信。但是,評估板的Web服務器無操作系統的,因此,它不需要創建獨立進程,而是通過調用相關函數直接進行CGI處理。評估板支持用於更新網絡信息的”NETCONF.CGI”和控制文本LCD、評估板發光二極管的的D1/D2的”LCDNLED.CGI”,圖3.23>和<圖3.24>顯示了兩個圖像處理的過程。

NETCONF.CGI的<FORM>不是通過查詢字符串方式,而是通過”POST”方式,並通過HTTP請求消息的實體進行提交。這樣的NETCONF.CGI參數值也可以使用get_http_param_value()函數提取相關參數值。
LCDNLED.CGI的<FORM>通過”GET”方式提交,請求地址的查詢字符串通過”GET”方式提交。通過請求地址的查詢字符串方式提交的參數也可以通過使用get_http_param_value()函數獲取。

3.2.6.5. DHCP客戶端
DHCP客戶端程序是一個在網絡的DHCP服務器分配網絡信息的程序。注意DHCP客戶端程序必須先於其他程序啟動,因為它負責管理網絡信息設置。首先在DHCP(動態主機配置協議)檢查基本情況,然後進一步使用DHCP客戶端程序。
DHCP在傳輸層使用UDP協議,並使用UDP廣播方式與DHCP服務器端進行通信。DHCP之所以使用UDP廣播方式,是因為它沒有IP地址,而且服務器端的IP是未知的。當使用W5100的UDP廣播通信時,若要實現廣播封裝傳輸,需要將目的IP地址設置成’255.255.255.255’。

<圖3.25>所示為DHCP服務器端與客戶端通信的信息流。

首先,DHCP客戶端向當地網絡播送DISCOVERY消息,如果DHCP服務器端在網絡中存在,就接收DISCOVERY消息並提供DHCP客戶端可以使用的網絡信息,例如IP地址、默認網關、子網掩碼和DNS地址,同時DHCP服務器還提供信息給DHCP客戶端,例如租約期限。DHCP客戶端通過接收到的信息檢測DHCP服務器,並利用DHCP服務器提供的信息給DHCP服務器端發送REQUEST消息。從DHCP客戶端接收到REQUEST消息後,DHCP服務器端檢測請求的網絡信息是否可用,如果可用,就發送ACK消息給DHCP客戶端;如果不可用,就發送NACK消息。從DHCP服務器接收到ACK消息後,DHCP客戶端就使用DHCP服務器提供的網絡信息,該網絡信息只有在DHCP服務器建議的租約期限內有效。因此,如果DHCP客戶端想繼續使用網絡信息,通常在租約期限過半的時候,重新發送REQUEST消息給DHCP服務器端來維持網絡信息。在這個過程中,DHCP客戶端可以從DHCP服務器獲取相同或者新的網絡信息,如果收到新的網絡信息,就必須使用新的。

DHCP服務器端與客戶端傳送的544字節信息格式如<圖3.26>所示。想了解每個DHCP信息格式字段的詳細解釋,參見‘RFC1541’文檔。第一個字節的op.字段決定了請求/響應,ciaddr後面的字段用於傳輸網絡信息,312字節的options字段用於傳輸消息類型或信息,例如客戶標識符。

<圖3.26>所示的DHCP信息通過RIP_MSG數據類型管理,其定義如<表3-33>所示,參見“inet/dhcp.h”。

我們來簡要的看一下DHCP信息的Option字段,格式如<圖3.27>所示。它包括Magic Cookie字段、一個4字節的租約識別Cookie和從代碼0到代碼255變化的代碼設置。從代碼1到代碼254,代碼由{Code, Len, Value}組成,代碼0和代碼255僅由代碼組成。想了解Option字段的每段代碼的更多解釋,參見RFC1533。

在312字節的Option字段中,未使用的字節用0填充。

 

這是本文的第五部分內容,後面的內容我們將會在今後的博文一一介紹,希望對大家有所幫助。歡迎大家的留言討論。

 

更多有關W5100的博文請看這裡:

http://blog.iwiznet.cn/?page_id=329

全硬件TCP/IP嵌入式以太網控制器——W5100E01-AVR http://blog.iwiznet.cn/?p=432

開源硬件-開源思潮到了? http://blog.iwiznet.cn/?p=316

WIZnet員工Richard培訓筆記: WIZnet核心技術和產品對比 http://blog.iwiznet.cn/?p=29

 

也可進入我們的官方網站或博客查看更多。

如果您對WIZnet的產品或是技術感興趣,請隨時與我們聯繫。

可以直接留言或登錄WIZnet官方網站:http://www.iwiznet.cn

公司微博是: http://weibo.com/wiznet2012

公司博客是:http://blog.iwiznet.cn/