摘要: 通過對TCP/IP協議的分析,結合嵌入式系統的特點,挑選出一套精簡、實用的TCP/IP協議子集,并詳細介紹各協議層的實現過程。為嵌入式網絡系統的開發提供一個較為簡單且可行的思路。
關鍵詞:嵌入式系統,以太網,TCP/IP協議, UDP, ARP
1、引言
    嵌入式網絡系統就是在嵌入式設備上">

      技術頻道

      嵌入式系統中TCP/IP協議的精簡與實現

      摘要: 通過對TCP/IP協議的分析,結合嵌入式系統的特點,挑選出一套精簡、實用的TCP/IP協議子集,并詳細介紹各協議層的實現過程。為嵌入式網絡系統的開發提供一個較為簡單且可行的思路。
      關鍵詞:嵌入式系統,以太網,TCP/IP協議, UDP, ARP
      1、引言
      嵌入式網絡系統就是在嵌入式設備上實現了網絡互聯功能的系統,一般要求嵌入式設備在軟件上支持TCP/IP協議棧,實現有關的以太網通信協議。如何實現TCP/IP協議是嵌入式網絡系統的關鍵技術之一,在嵌入式系統中應用TCP/IP協議的關鍵是,如何設計出精簡、高效的TCP/IP協議子集,以此來減少對系統資源的占用。
      目前使用廣泛的TCP/IP協議棧有LWIP(Light Weight)、uIP、Linux IP等,這些協議棧具有一定的通用性,包含的協議內容比較全,同時也比較復雜。具體在移植到應用系統的時候要考慮的問題較多,各個庫文件和全局變量相互交叉引用,若要針對特定系統進行精簡,則牽一發而動全身,尤其是存儲器的管理及上層協議與底層網絡驅動的接口是兩個最大的移植難題。
      為了能對TCP/IP協議有較深的了解,又利于后期進行深入研究,我們在實現一具體的Internet網絡報警系統時,進行自主的嵌入式TCP/IP協議開發。下文所介紹的TCP/IP協議系統由于精簡而利于實現,且無需進行內存管理,適合傳送數據量不大的嵌入式系統。在實現時,只要根據相應的數據幀格式,在各層完成相應的功能即可。非常適合研究學習之用,為嵌入式網絡系統的開發提供一個較為可行且簡單的思路。
      2、協議的分析與選擇
      眾所周知,TCP/IP是一個協議族,是幾百種網絡協議的集合。通用計算機系統有足夠的資源支持通信協議在內核實現,但是嵌入式系統則不同,因為其CPU處理能力和系統存儲能力都受到成本限制,充分利用資源、提高系統性價比是開發嵌入式應用的根本特點。所以要對TCP/IP協議進行精簡以適應嵌入式系統。
      下面我們以實際的Internet網絡報警系統為例,設計一個較為精簡的TCP/IP協議子系統。此系統采用32位ARM結構的三星S3C440BX處理器,加SMSC公司的以太網控制芯片LAN91C113,以及另外一些外圍芯片組成。此系統要求經Internet傳送一些現場采集的報警數據到遠程站點,要求實時性好、傳輸速度快,但每次傳輸的數據量很少,只是簡單的報警信息。根據這些要求,再經詳細分析TCP/IP各協議層實現的功能,精簡出的協議子集如圖1:

      層次

      需要實現的協議

      應用層

      傳輸層

      UDP

      網絡層

      IP、ICMP中的Ping響應協議

      鏈路層

      ARP應答協議

      圖1 精簡的TCP/IP協議子集

      首先在鏈路層上,由于采用以太網的接入方式,系統必須要實現IEEE802.3所規定的CDMA/CD協議。CDMA/CD協議不需用戶實現,此協議只要采用通用的以太網接口芯片就可支持。其次,為了保證系統在以太網中的通信,系統還需實現ARP應答協議,該協議用于將IP地址映射成以太網MAC地址。ARP的執行依靠維持一張表來完成IP地址和MAC的地址的映射。
      在網絡層,由于系統要求能夠在Internet進行通信,因此系統要實現IP協議。IP層的代碼有兩個功能:驗證到來的IP報文報頭的正確性,并且對TCP和ICMP報文實行分流。因為不考慮IP的分片和重組,所以 IP層的代碼非常的精簡。為了能夠測試系統與網絡的連接,系統需要實現ICMP協議中的Ping應答協議,Ping應答協議主要是檢查網絡是否連通
      在傳輸層, TCP為兩臺主機提供面向連接的、可靠的、無重復的雙向數據流傳輸服務,TCP協議設計了嚴格的3次建立連接握手過程、4次關閉連接握手過程,這些過程的實現對系統資源的耗費非常大。而UDP的實現比較簡單,它在某些嵌入式Internet的應用場合可以很好地應用。考慮到系統的簡化及速度的要求,采用了UDP協議,為了確保UDP數據的到達,在應用程序中采用了重復發送、回復確認的方式來保證數據的正確性。
      由于本嵌入式系統無HTTP、FTP等應用,所以應用層中的協議無需實現。
      3、協議的實現
      本系統由于協議比較精簡,只保留了必須使用的一些協議,所以實現過程相對簡單。實現過程中的一個總目標是系統開銷要少,每一層之間要相互獨立,內存操作簡單。為了實現每一層的獨立,實現上下層之間的數據透明傳輸。每層之間應通過一系列的函數進行數據傳遞,同時為了減少由于數據拷貝引入的系統開銷,系統應通過指針操作,而不是數據拷貝方式,將緩沖區中的數據沿協議棧向上傳遞。
      由于TCP/IP的各層協議的各種數據格式,在各種資料中都有詳細說明,這里就不再一一介紹。只詳細介紹總的結構、各層的功能及實現過程,為了便于調試,系統在實現時肯定是從底層開始,一層一層往上實現。
      1) 首先公共數據結構的定義:如MAC地址格式、IP地址格式、系統的地址配置、緩沖區格式及大小。
      其中MAC、IP地址格式都是固定的,系統的配置用于確定系統的IP地址及端口以及MAC地址值。在本系統中由于傳送的數據有限,只定義了4個用于傳送和接收數據的緩沖區每個長度為150字節。
      2)網絡驅動接口:由于網絡驅動也是我們自己編制的,所以與上層結合起來很順利,接收時采用中斷機制,當收到網絡中斷就讀取數據,根據包的種類分別傳給ARP或IP協議,由每一層自行處理數據。發送時采用查詢方式,應用層準備好數據,一層層封裝并向下傳遞,最后經由網絡驅動程序發送。
      3) 鏈路層ARP協議的實現:
      首先定義ARP數據幀頭結構及ARP高速緩沖表,數據幀必須根據標準定義,高速緩沖表至少要含有IP地址及相對應的MAC地址兩項。由于嵌入式系統所連接的對象數目較少且都比較固定,所以就去掉了緩沖表的定時刷新程序,這樣可以大大減少系統的刷新開銷。
      這一部分的主要工作是:
      a、根據上層數據包中的IP地址,在高速緩沖表中查出對應的MAC地址并填入包中相應位置。若表中沒有相應MAC地址,則按照格式組裝一個ARP請求包并發送,以得到對方MAC地址。
      b、若收到ARP應答包,則更新ARP緩存表。
      主要函數有:
      struct pbuf * arp_packet(struct arpdata *q)// 把要發送的ARP數據打包成網絡格式字節流;
      struct mac *arp_lookup (struct ip *p) // 根據IP地址在ARP緩存表中查找MAC地址,若找不到則自動向網絡廣播ARP請求;
      void arp_input(struct pbuf *p)// 從驅動程序傳入ARP幀數據,如果是ARP請求則發送一個ARP應答包,如果是ARP應答則更新ARP緩存表;
      4)網絡層IP協議及Ping應答的實現:
      首先定義數據結構IP及ICMP數據幀格式,這兩者都要根據標準來定義。這一部分的主要工作有:
      a、對上一層傳下來的數據包,加上IP首部和IP校驗和,發往下一層。以及對下一層傳上來的數據包,進行校驗和檢查,若正確去掉IP首部,送往上一層。
      b、為了便于測試要響應主機的PING程序,即如收到ICMP的回顯請求包,則按照格式組裝一個ICMP的回顯應答包并發送。
      主要函數有:
      int ip_input(struct pbuf* p);//輸入下一層的數據包,去掉IP首部傳給上一層;
      int ip_send_data(struct pbuf *p,int len,int type,struct ip dst_ip);//將上一層的數據加上IP首部,并向下一層發送;
      void ip_packet(struct pbuf *p,struct IP_data *q,int len);//IP首部和數據打包;
      U16 ip_chksum(U8 *p,int len);//IP檢驗和計算;
      void icmp_input(struct pbuf *p) 如果ICMP的回顯請求,則發一個應答包;
      5)傳輸層UDP協議的實現:
      根據標準定義UDP數據幀格式。這一部分的主要工作有:對應用層傳下來的數據包,加上UDP首部和UDP校驗和,發往下一層。以及對下一層傳上來的數據包,進行校驗和檢查,若正確去掉UDP首部,提出數據送給應用層。需注意的是,要產生一個偽首部用于UDP數據檢驗和計算。
      主要函數有:
      void udp_input(struct pbuf *p);//從下一層輸入UDP數據
      void udp_output(U8 *str,struct ip dst_ip,U16 dst_port);//向下一層發送UDP數據
      void makeup_pheader(struct ip *p,U16 len ,U8 *q);//產生偽首部用于UDP檢驗和計算
      U16 udp_chksum(U8 *p,int len,U8 *p1,int len1);//計算UDP檢驗和
      6)執行過程:
      當本地系統有數據要發送時,首先在傳輸層將數據加上UDP首部,再到網絡層加IP首部,然后到鏈路層從ARP表中查詢相應的MAC地址,填入相應位置,并發給網絡驅動程序傳到以太網上。
      圖2是用SPYNET軟件截取的本系統啟動后第一次發送一串字符的整個網絡協議應答過程,由于是第一次發送, ARP表為空。所以當發送UDP數據時找不到目的IP地址對應的MAC地址,系統先發ARP請求,等對方回一個ARP應答,得到對方MAC地址,然后再發UDP數據包。

      圖2 一個實際UDP數據包發送全過程

      4、結束語
      由于嵌入式系統發展及互聯網絡的普及、遠程控制和信息家電的興起,嵌入式系統與互聯網絡的結合逐漸成為一種新的技術發展方向,嵌入式TCP/IP協議的選擇與實現是這一技術必須要面對的。很多時候在涉及TCP/IP協議時,都容易被其復雜的體系結構所迷惑,而不敢輕易動手,本文提出的這種嵌入式TCP/IP協議的選擇思路及給出的一套精簡TCP/IP協議子集的實現過程,對于這一方面的研究很具有參考價值。


      文章版權歸西部工控xbgk所有,未經許可不得轉載。

      主站蜘蛛池模板: 后入内射国产一区二区| 99精品高清视频一区二区| 国产主播福利一区二区| 久久精品无码一区二区三区| 亚洲无线码一区二区三区| 性色av一区二区三区夜夜嗨| 精品欧洲av无码一区二区三区| 中文字幕日韩丝袜一区| 免费看无码自慰一区二区| 亚洲中文字幕丝袜制服一区| 日本免费电影一区二区| 亚洲Av无码国产一区二区| 精品女同一区二区三区免费播放| 久久久久国产一区二区| 老熟女五十路乱子交尾中出一区| 色综合视频一区二区三区44| 国产情侣一区二区三区| 无码精品一区二区三区在线| 秋霞日韩一区二区三区在线观看 | 四虎永久在线精品免费一区二区 | 一区二区三区久久精品| 中文字幕aⅴ人妻一区二区| 亚洲狠狠狠一区二区三区| 精品一区二区AV天堂| 久久久精品人妻一区亚美研究所| 中文字幕AV一区二区三区| 一区二区三区福利视频| 精品女同一区二区三区免费站| 日本高清无卡码一区二区久久| 久久国产精品最新一区| 无码午夜人妻一区二区不卡视频| 色噜噜AV亚洲色一区二区| 久久久国产精品无码一区二区三区 | 无码中文人妻在线一区| 中文无码AV一区二区三区| 国内精品一区二区三区最新| 无码人妻精品一区二区三区在线| 波多野结衣av高清一区二区三区| 日韩精品一区二区三区中文| 久久se精品一区精品二区国产| 四虎在线观看一区二区|