新聞中心

EEPW首頁(yè) > 網(wǎng)絡(luò)與存儲(chǔ) > 設(shè)計(jì)應(yīng)用 > VxWorks中以太網(wǎng)通信報(bào)文的粘連問題

VxWorks中以太網(wǎng)通信報(bào)文的粘連問題

作者:北京交通大學(xué) 張明 鄭偉 陜西國(guó)華錦界能源有限公司 張福仲 時(shí)間:2008-06-27 來(lái)源:?jiǎn)纹瑱C(jī)與嵌入式系統(tǒng)應(yīng)用 收藏

  是美國(guó)Wind River公司推出的一款專門為實(shí)時(shí)系統(tǒng)設(shè)計(jì)開發(fā)的操作系統(tǒng)內(nèi)核,為程序員提供了高效的實(shí)時(shí)多任務(wù)調(diào)度、中斷管理,實(shí)時(shí)的系統(tǒng)資源以及實(shí)時(shí)的任務(wù)間通信。它是一種功能強(qiáng)大而且比較復(fù)雜的操作系統(tǒng),包括進(jìn)程管理、存儲(chǔ)管理、設(shè)備管理、文件系統(tǒng)管理、網(wǎng)絡(luò)協(xié)議及系統(tǒng)應(yīng)用等部分。目前應(yīng)用已經(jīng)十分廣泛,從數(shù)碼相機(jī)、路由器到B2隱形轟炸機(jī)、火星探路者,都有它的身影。在863某交通重大專項(xiàng)計(jì)劃控制系統(tǒng)國(guó)產(chǎn)化研究項(xiàng)目中,分區(qū)控制計(jì)算機(jī)(DCC)和電機(jī)控制單元(MCU)也都采用了操作系統(tǒng)。在現(xiàn)場(chǎng)測(cè)試過程中,我們發(fā)現(xiàn)基于TCP/IP網(wǎng)絡(luò)協(xié)議傳輸?shù)臄?shù)據(jù)有時(shí)會(huì)出現(xiàn)現(xiàn)象(即發(fā)送方發(fā)送的若干包數(shù)據(jù)傳輸?shù)浇邮辗綍r(shí)粘成一包)。針對(duì)這種情況,我們進(jìn)行了專題研究與實(shí)驗(yàn)。本文重點(diǎn)分析了問題,并結(jié)合實(shí)驗(yàn)結(jié)果提出了解決該問題的對(duì)策和方法。

本文引用地址:http://2s4d.com/article/84902.htm

  1 報(bào)文粘連問題的現(xiàn)象及分析

  1.1 報(bào)文粘連問題的現(xiàn)象

  TCP/IP報(bào)文粘連是指發(fā)送方發(fā)送的若干包數(shù)據(jù),在接收方接收到時(shí)粘成一包,即后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。由于報(bào)文長(zhǎng)度與接收緩沖區(qū)長(zhǎng)度有可能不成整倍數(shù)關(guān)系,所以粘連在一起的報(bào)文中有不完整的包。VxWorks操作系統(tǒng)會(huì)先將由網(wǎng)絡(luò)傳輸來(lái)的數(shù)據(jù)放入系統(tǒng)接收緩沖區(qū)中,以備用戶進(jìn)程從中調(diào)用數(shù)據(jù)。此處假設(shè)接收方緩沖區(qū)長(zhǎng)為L(zhǎng)字節(jié),L應(yīng)有一定的長(zhǎng)度,以保證至少可以存儲(chǔ)一包數(shù)據(jù)。由于DCC和MCU之間需要傳輸不同種類的報(bào)文來(lái)進(jìn)行數(shù)據(jù)交互,所以用戶在程序中應(yīng)為不同的報(bào)文分別設(shè)置不同的接收緩沖區(qū)來(lái)存放不同的報(bào)文數(shù)據(jù)。此處假設(shè)只有應(yīng)答報(bào)文和狀態(tài)報(bào)文兩種,分別以用戶緩沖區(qū)1和2來(lái)存儲(chǔ);長(zhǎng)度應(yīng)與用戶層對(duì)應(yīng)報(bào)文的長(zhǎng)度相等,假設(shè)分別為m和n。情況如圖1所示。


圖1 粘包情況示意圖

  1.2 報(bào)文粘連問題的分析

  報(bào)文粘連既可能由發(fā)送方產(chǎn)生,也可能由接收方產(chǎn)生,還可能由進(jìn)行數(shù)據(jù)傳輸?shù)慕粨Q機(jī)產(chǎn)生。

  (1) 發(fā)送方引起的報(bào)文粘連

  由發(fā)送方引起的報(bào)文粘連是源于TCP協(xié)議本身。因?yàn)門CP協(xié)議為提高傳輸效率采用了Nagle算法(詳見RFC896),發(fā)送方要等收集到1460字節(jié)的數(shù)據(jù)才會(huì)發(fā)送一包數(shù)據(jù),或是等到發(fā)送緩沖區(qū)滿后才會(huì)發(fā)送一包數(shù)據(jù),這就造成了報(bào)文的粘連。

  (2) 接收方引起的報(bào)文粘連

  由接收方引起的報(bào)文粘連,往往是因?yàn)榻邮辗竭M(jìn)程沒有及時(shí)處理數(shù)據(jù)造成的。接收方要先把收到的數(shù)據(jù)放入接收數(shù)據(jù)緩沖區(qū),用戶進(jìn)程再?gòu)脑摼彌_區(qū)中讀取數(shù)據(jù)。如果在下一包數(shù)據(jù)到達(dá)時(shí)前一包數(shù)據(jù)還未被用戶進(jìn)程取走,則新一包數(shù)據(jù)就接到前一包數(shù)據(jù)之后,而用戶要根據(jù)事先設(shè)定好的緩沖區(qū)大小從系統(tǒng)接收緩沖區(qū)中讀取數(shù)據(jù),這就造成了一次取到了多包數(shù)據(jù)。

  (3) 由交換機(jī)引起的報(bào)文粘連

  由交換機(jī)引起的報(bào)文粘連,往往是因?yàn)橛山粨Q機(jī)相連的各個(gè)部件在一段時(shí)間內(nèi)發(fā)送的報(bào)文數(shù)據(jù)太多,以至于超出了交換機(jī)的處理能力。這樣,本來(lái)發(fā)送端分開發(fā)送的數(shù)據(jù)報(bào)文在交換機(jī)內(nèi)部的緩沖區(qū)中粘連在一起。現(xiàn)在,在實(shí)驗(yàn)現(xiàn)場(chǎng)DCC等使用VxWorks操作系統(tǒng)的部件需要使用一個(gè)獨(dú)立的端口進(jìn)行程序下載,還要有一個(gè)獨(dú)立的端口提供給SecureCRT軟件以進(jìn)行實(shí)時(shí)監(jiān)控;同時(shí)DCC與MCU和中央控制系統(tǒng)的數(shù)據(jù)傳輸也要在同一臺(tái)交換機(jī)中進(jìn)行。這就有可能導(dǎo)致在某一段時(shí)間內(nèi)數(shù)據(jù)量超過了交換機(jī)的處理能力。

  1.3 文粘連對(duì)系統(tǒng)的影響

  如果系統(tǒng)發(fā)生了報(bào)文粘連現(xiàn)象而不進(jìn)行相應(yīng)處理,則將導(dǎo)致整個(gè)系統(tǒng)無(wú)法正常運(yùn)行。

  如果用于傳輸數(shù)據(jù)的報(bào)文被粘連導(dǎo)致無(wú)法正常處理,則將使接收方無(wú)法進(jìn)行運(yùn)算,現(xiàn)場(chǎng)實(shí)時(shí)的數(shù)據(jù)無(wú)法獲得,從而使標(biāo)志位無(wú)法置位,程序無(wú)法繼續(xù)進(jìn)行。如果作為生命信號(hào)的報(bào)文被粘連導(dǎo)致無(wú)法正常處理,則將使接收方認(rèn)為發(fā)送方出現(xiàn)故障;若此情況連續(xù)發(fā)生,則接收方將認(rèn)為發(fā)送方死機(jī),從而停機(jī),以保證整個(gè)系統(tǒng)的安全。

  2 報(bào)文粘連問題的解決方法

  2.1 發(fā)送方的解決方法

  對(duì)于由發(fā)送方引起的報(bào)文粘連,可以采用以下兩種方法解決。

 ?。?) 關(guān)閉Nagle算法

  由于VxWorks系統(tǒng)支持Windows Sockets 1.1標(biāo)準(zhǔn),可以將setsockopt函數(shù)中的level項(xiàng)設(shè)置為IPPROTO_TCP1,這樣就可以關(guān)閉Nagle優(yōu)化算法。

 ?。?) 將Winsock kernel buffer設(shè)置為0

  此方法只有在支持Windows Sockets 2.0標(biāo)準(zhǔn)的系統(tǒng)上才能使用(VxWorks不能支持),可在發(fā)送方為工控機(jī)、接收方為使用VxWorks操作系統(tǒng)的處理器的情況下使用。只需將setsockopt項(xiàng)中的level設(shè)為SOL_SOCKET,將SO_SNDBUF值設(shè)為0。

tcp/ip相關(guān)文章:tcp/ip是什么



上一頁(yè) 1 2 下一頁(yè)

評(píng)論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉