VxWorks中以太網(wǎng)通信報(bào)文的粘連問(wèn)題
作者:北京交通大學(xué) 張明 鄭偉 陜西國(guó)華錦界能源有限公司 張福仲
時(shí)間:2008-06-27
來(lái)源:?jiǎn)纹瑱C(jī)與嵌入式系統(tǒng)應(yīng)用
收藏
2.2 接收方的解決方法
對(duì)于由接收方引起的報(bào)文粘連,也有兩種方法解決。
?。?) 提高報(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。
?。?) 將粘連在一起的報(bào)文進(jìn)行分包處理
此方法是規(guī)定報(bào)文數(shù)據(jù)某一位的內(nèi)容為該幀報(bào)文數(shù)據(jù)的總長(zhǎng)度,接收方先提取出此內(nèi)容,如果緩沖區(qū)中的數(shù)據(jù)長(zhǎng)度大于等于該長(zhǎng)度,則按該內(nèi)容的長(zhǎng)度從緩沖區(qū)中提取數(shù)據(jù);如果長(zhǎng)度不夠則不提取數(shù)據(jù),等到長(zhǎng)度達(dá)到要求時(shí)再提取數(shù)據(jù)。這樣即使出現(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 分包處理過(guò)程
2.3 交換機(jī)的解決方法
對(duì)于由交換機(jī)引起的報(bào)文粘連,有3種解決方法:
?。?) 使用有更強(qiáng)處理能力的交換機(jī)
可使用處理能力更強(qiáng)、擁有較大緩存空間的交換機(jī)??墒悄壳皩?shí)驗(yàn)現(xiàn)場(chǎng)已經(jīng)使用了某外國(guó)著名廠商的16口交換機(jī),且該交換機(jī)有1MB的緩存空間,使用更高檔的交換機(jī)無(wú)疑會(huì)使成本增高。
?。?) 增加交換機(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ò)癱瘓。所以,不建議使用此方法。
?。?) 修改對(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è)置為0后粘包問(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)行情況良好。
參考文獻(xiàn)
[1] Nagle J. Congestion Control in IP/TCP Internet works[S]. RFC896,1984.
[2] 陳智育,溫彥軍,陳琪.VxWorks程序開(kāi)發(fā)實(shí)踐[M].北京:人民郵電出版社,2004.
[3] 鄺堅(jiān).Tornado/VxWorks入門(mén)與提高[M].北京:科學(xué)出版社,2004.
[4] WindRiver. VxWorks for PowerPC Architecture Reference 5.5,2003.
tcp/ip相關(guān)文章:tcp/ip是什么
評(píng)論