技術(shù)頻道

娓娓工業(yè)
您現(xiàn)在的位置: 中國(guó)傳動(dòng)網(wǎng) > 技術(shù)頻道 > 技術(shù)百科 > VxWorks中以太網(wǎng)通信報(bào)文的粘連問(wèn)題

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

時(shí)間:2008-03-21 16:14:00來(lái)源:mahaiyan

導(dǎo)語(yǔ):?分析了TCP/IP協(xié)議的粘包問(wèn)題,并結(jié)合實(shí)驗(yàn)結(jié)果提出了解決該問(wèn)題的對(duì)策和方法。
VxWorks是一種功能強(qiáng)大而且比較復(fù)雜的操作系統(tǒng),包括進(jìn)程管理、存儲(chǔ)管理、設(shè)備管理、文件系統(tǒng)管理、網(wǎng)絡(luò)協(xié)議及系統(tǒng)應(yīng)用等部分。目前VxWorks應(yīng)用已經(jīng)十分廣泛,從數(shù)碼相機(jī)、路由器到B-2隱形轟炸機(jī)、火星探路者,都有它的身影。在863某交通重大專(zhuān)項(xiàng)計(jì)劃控制系統(tǒng)國(guó)產(chǎn)化研究項(xiàng)目中,分區(qū)控制汁算機(jī)(DCC)和電機(jī)控制單元(MCU)也都采用了VxWorks操作系統(tǒng)。在現(xiàn)場(chǎng)測(cè)試過(guò)程中,我們發(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)行了專(zhuān)題研究與實(shí)驗(yàn)。本文重點(diǎn)分析了TCP/IP協(xié)議的粘包問(wèn)題,并結(jié)合實(shí)驗(yàn)結(jié)果提出了解決該問(wèn)題的對(duì)策和方法。 1 報(bào)文粘連問(wèn)題的現(xiàn)象及分析 1.1 報(bào)文粘連問(wèn)題的現(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)程從中凋用數(shù)據(jù)。此處假設(shè)接收方緩沖區(qū)長(zhǎng)為L(zhǎng)字節(jié),L應(yīng)有一定的長(zhǎng)度,以保證至少可以存儲(chǔ)一包數(shù)據(jù)。由于DCC和MCU之間需要傳輸不同種類(lèi)的報(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米存儲(chǔ);長(zhǎng)度應(yīng)與用戶層對(duì)應(yīng)報(bào)文的長(zhǎng)度相等,假設(shè)分別為m和n。粘包情況如圖1所示。
1.2 報(bào)文粘連問(wèn)題的分析 報(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)門(mén)CP協(xié)議為提高傳輸效率采用了Nagle算法(詳見(jiàn)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)程沒(méi)有及時(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ā)送端分開(kāi)發(fā)送的數(shù)據(jù)報(bào)文在交換機(jī)內(nèi)部的緩沖區(qū)中粘連在一起?,F(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ù)量超過(guò)了交換機(jī)的處理能力。 1.3 報(bào)文粘連對(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)文粘連問(wèn)題的解決方法 2.1 發(fā)送方的解決方法 對(duì)于由發(fā)送方引起的報(bào)文粘連,可以采用以下兩種方法解決。 (1)關(guān)閉Nagle算法 由于VxWorks系統(tǒng)支持Windows Socketsl.1標(biāo)準(zhǔn),可以將setsockopt函數(shù)中的1evel項(xiàng)設(shè)置為L(zhǎng)PPROTO_TCPl,這樣就可以關(guān)閉Nagle優(yōu)化算法。 (2)將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。 2.2 接收方的解決方法 對(duì)于南接收方引起的報(bào)文粘連,也有兩種方法解決。 (1)提高報(bào)文處理任務(wù)的優(yōu)先級(jí) 使用VxWorks操作系統(tǒng)可以方便地設(shè)置任務(wù)的優(yōu)先級(jí)。使用taskSpawn函數(shù)啟動(dòng)任務(wù),其中priority的數(shù)值就是任務(wù)的優(yōu)先級(jí)(從0~255,優(yōu)先級(jí)依次降低)。使用此函數(shù)將處理報(bào)文任務(wù)的優(yōu)先級(jí)設(shè)為比其他任務(wù)高,但是為了減小意外發(fā)生的可能,該值應(yīng)小于100,因?yàn)閠askSpawn的默認(rèn)優(yōu)先級(jí)為100。 (2)將粘連在一起的報(bào)文進(jìn)行分包處理 此方法是規(guī)定報(bào)文數(shù)據(jù)某一位的內(nèi)容為該幀報(bào)文數(shù)據(jù)的總長(zhǎng)度,接收方先提取出此內(nèi)容,如果緩沖區(qū)中的數(shù)據(jù)氏度大于等于該長(zhǎng)度,則按該內(nèi)容的長(zhǎng)度從緩沖區(qū)中提取數(shù)據(jù);如果長(zhǎng)度不夠則不提取數(shù)據(jù),等到長(zhǎng)度達(dá)到要求時(shí)再提取數(shù)據(jù)。這樣即使m現(xiàn)報(bào)文粘連現(xiàn)象,應(yīng)用程序也會(huì)將粘連在一起的數(shù)據(jù)進(jìn)行分包處理,不會(huì)出現(xiàn)數(shù)據(jù)丟失無(wú)法識(shí)別報(bào)文ID的情況。下面通過(guò)一個(gè)具體例子進(jìn)行詳細(xì)說(shuō)明。 在實(shí)驗(yàn)線上MCU發(fā)送給DCC的狀態(tài)報(bào)文長(zhǎng)度為84字節(jié)(報(bào)文ID為91H),應(yīng)答報(bào)文長(zhǎng)度為20字節(jié)(報(bào)文ID為81H),接收緩沖區(qū)為90字節(jié)。如果狀態(tài)報(bào)文粘連在應(yīng)答報(bào)文之后,則將使DCC無(wú)法收到完整的狀態(tài)報(bào)文。這種情況連續(xù)發(fā)生3次之后,DCC將認(rèn)為任務(wù)MCU發(fā)生故障,系統(tǒng)將停機(jī),因而結(jié)果必然是錯(cuò)誤的。如果將報(bào)文長(zhǎng)度放在報(bào)文的第一位中,報(bào)文ID放在第二位中,則進(jìn)行分包處理后就不會(huì)出現(xiàn)上述的診斷錯(cuò)誤。處理過(guò)程如圖2所示。
2.3 交換機(jī)的解決方法 對(duì)于由交換機(jī)引起的報(bào)文粘連,有3種解決方法: (1)使用有更強(qiáng)處理能力的交換機(jī) 可使用處理能力更強(qiáng)、擁有較大緩存空間的交換機(jī)??墒侨涨皩?shí)驗(yàn)現(xiàn)場(chǎng)已經(jīng)使用了某外國(guó)著名廠商的16口交換機(jī),且該交換機(jī)有1MB的緩存空間,使用更高檔的交換機(jī)無(wú)疑會(huì)使成本增高。 (2)增加交換機(jī)數(shù)量 可將1臺(tái)16口交換機(jī)的工作量交由2臺(tái)8口交換機(jī)來(lái)完成,再將這兩臺(tái)交換機(jī)進(jìn)行連接,這種方法可以明顯降低一臺(tái)交換機(jī)的數(shù)據(jù)處理負(fù)擔(dān),但會(huì)使系統(tǒng)的可靠性和安全性指標(biāo)大幅度降級(jí);而且隨著以后實(shí)驗(yàn)設(shè)備的增加,不斷連接新交換機(jī)的方法有可能使網(wǎng)絡(luò)形成環(huán)路,這將造成網(wǎng)絡(luò)癱瘓。所以,不建議使用此方法。 (3)修改對(duì)交換機(jī)的配置 可通過(guò)修改相關(guān)參數(shù)將交換機(jī)數(shù)據(jù)傳輸方式設(shè)置為無(wú)等待傳輸,即在交換機(jī)得到數(shù)據(jù)后不放入內(nèi)部緩沖區(qū),而是直接交給接收方。這種方式在一定程度上可以避免粘包現(xiàn)象的發(fā)生,但當(dāng)報(bào)文傳輸很緊密時(shí)也有繼續(xù)產(chǎn)生粘包現(xiàn)象的可能。 3 結(jié)論 通過(guò)對(duì)發(fā)送方和接收方4種解決方法的現(xiàn)場(chǎng)實(shí)驗(yàn),我們發(fā)現(xiàn)效果不盡相同。 ①在關(guān)閉Nagle算法的情況下,發(fā)現(xiàn)Nagle算法依然在使用。最終的結(jié)論是,這是Winsock的一個(gè)BUG,并且已經(jīng)在微軟的BUG目錄中得到了證實(shí),所以此方法無(wú)效。 ②將Winsock kernel buffer設(shè)置為O后粘包問(wèn)題得到了解決,但傳輸速度明顯降低。經(jīng)測(cè)試,每秒大概只能傳送5幀數(shù)據(jù),這在VxWorks這種硬實(shí)時(shí)系統(tǒng)中是無(wú)法接受的。 ③提高報(bào)文處理任務(wù)優(yōu)先級(jí)的方法可以對(duì)報(bào)文粘連起到防治,但有可能產(chǎn)生一些易發(fā)現(xiàn)的任務(wù)調(diào)度問(wèn)題。 ④分包處理的方法雖然不能防止粘連的發(fā)生,但是可以完全防止報(bào)文粘連對(duì)系統(tǒng)產(chǎn)生的影響。 實(shí)踐證明,使用分包處理的方法可以在高速數(shù)據(jù)傳輸?shù)那闆r下保證傳輸?shù)恼_性,而且不會(huì)產(chǎn)生任何副作用,對(duì)處理速度的影響也很小,可以忽略不計(jì)。這種方法已經(jīng)在實(shí)驗(yàn)現(xiàn)場(chǎng)使用了很長(zhǎng)一段時(shí)間,運(yùn)行情況良好。

標(biāo)簽:

點(diǎn)贊

分享到:

上一篇:基于FF總線實(shí)現(xiàn)水箱系統(tǒng)動(dòng)態(tài)...

下一篇:微能WIN-V63矢量控制變頻器在...

中國(guó)傳動(dòng)網(wǎng)版權(quán)與免責(zé)聲明:凡本網(wǎng)注明[來(lái)源:中國(guó)傳動(dòng)網(wǎng)]的所有文字、圖片、音視和視頻文件,版權(quán)均為中國(guó)傳動(dòng)網(wǎng)(www.treenowplaneincome.com)獨(dú)家所有。如需轉(zhuǎn)載請(qǐng)與0755-82949061聯(lián)系。任何媒體、網(wǎng)站或個(gè)人轉(zhuǎn)載使用時(shí)須注明來(lái)源“中國(guó)傳動(dòng)網(wǎng)”,違反者本網(wǎng)將追究其法律責(zé)任。

本網(wǎng)轉(zhuǎn)載并注明其他來(lái)源的稿件,均來(lái)自互聯(lián)網(wǎng)或業(yè)內(nèi)投稿人士,版權(quán)屬于原版權(quán)人。轉(zhuǎn)載請(qǐng)保留稿件來(lái)源及作者,禁止擅自篡改,違者自負(fù)版權(quán)法律責(zé)任。

網(wǎng)站簡(jiǎn)介|會(huì)員服務(wù)|聯(lián)系方式|幫助信息|版權(quán)信息|網(wǎng)站地圖|友情鏈接|法律支持|意見(jiàn)反饋|sitemap

中國(guó)傳動(dòng)網(wǎng)-工業(yè)自動(dòng)化與智能制造的全媒體“互聯(lián)網(wǎng)+”創(chuàng)新服務(wù)平臺(tái)

網(wǎng)站客服服務(wù)咨詢采購(gòu)咨詢媒體合作

Chuandong.com Copyright ?2005 - 2024 ,All Rights Reserved 版權(quán)所有 粵ICP備 14004826號(hào) | 營(yíng)業(yè)執(zhí)照證書(shū) | 不良信息舉報(bào)中心 | 粵公網(wǎng)安備 44030402000946號(hào)