王銀,俞建定,王新彪,萬(wàn)旭東
(寧波大學(xué)信息科學(xué)與工程學(xué)院,浙江 寧波 315211)
工業(yè)手持終端的通信設(shè)計(jì)
王銀,俞建定,王新彪,萬(wàn)旭東
(寧波大學(xué)信息科學(xué)與工程學(xué)院,浙江 寧波 315211)
該通信方案以工業(yè)手持終端現(xiàn)場(chǎng)應(yīng)用為背景,針對(duì)傳統(tǒng)以太網(wǎng)在工業(yè)通信中實(shí)時(shí)性差的問(wèn)題,提出了一種發(fā)送心跳包,建立socket長(zhǎng)連接的方法,由此來(lái)減少通信過(guò)程中頻繁建立和關(guān)閉連接所消耗的時(shí)間。運(yùn)用XMPP協(xié)議實(shí)現(xiàn)輕量級(jí)、簡(jiǎn)單實(shí)用的消息推送組件,可以進(jìn)行服務(wù)端消息推送從而代替了傳統(tǒng)的客戶(hù)端輪詢(xún)機(jī)制,縮短了響應(yīng)時(shí)間,提高了整個(gè)系統(tǒng)的實(shí)時(shí)性。
手持終端 socket 心跳包 消息推送 實(shí)時(shí)性
近年來(lái),由于以太網(wǎng)開(kāi)放程度高、數(shù)據(jù)吞吐量大、通信速率快等特點(diǎn),使其成為各行各業(yè)最受歡迎的通信網(wǎng)絡(luò)之一。它不僅壟斷了辦公自動(dòng)化領(lǐng)域的網(wǎng)絡(luò)通信,而且廣泛應(yīng)用于工業(yè)控制領(lǐng)域資源管理等中上層通信網(wǎng)絡(luò),并有向下應(yīng)用于工業(yè)控制現(xiàn)場(chǎng)的趨勢(shì)。實(shí)時(shí)性差是它應(yīng)用于工業(yè)現(xiàn)場(chǎng)的一大障礙。為解決上述問(wèn)題,人們提出了很多方法,如在原有以太網(wǎng)基礎(chǔ)上修改開(kāi)發(fā)新的實(shí)時(shí)通信協(xié)議,但這又面臨著開(kāi)發(fā)難度較高且周期漫長(zhǎng)的問(wèn)題;又如對(duì)原有硬件進(jìn)行改動(dòng)等方法,但這些又無(wú)疑加大了工業(yè)的應(yīng)用成本。為此,本文提出了一種基于socket的局域網(wǎng)實(shí)時(shí)通信的設(shè)計(jì)和實(shí)現(xiàn)方法,并深入探討了socket的工作原理和通信方式。而且結(jié)合實(shí)際應(yīng)用需要,詳細(xì)闡述了通過(guò)心跳機(jī)制和消息推送的方法來(lái)提高工業(yè)終端實(shí)時(shí)通信的原理及其實(shí)現(xiàn)流程。
Socket又稱(chēng)套接字,是對(duì)傳輸層協(xié)議(UDP和TCP)的一種封裝。應(yīng)用層的程序通過(guò)傳輸層協(xié)議進(jìn)行數(shù)據(jù)的傳輸,而socket的作用是將應(yīng)用層的程序添加到網(wǎng)絡(luò)中,然后和其他處于同網(wǎng)絡(luò)中的應(yīng)用層程序進(jìn)行通信。簡(jiǎn)單來(lái)說(shuō),socket是傳輸層供給應(yīng)用層的函數(shù)調(diào)用接口,它提供了程序內(nèi)部與外界通信的端口并為通信的雙方提供了數(shù)據(jù)傳輸?shù)耐ǖ馈ocket的工作原理如圖1所示:
圖1 Socket的工作原理
2.1 Socket通信方式
根據(jù)不同的通信協(xié)議,socket共有3種常見(jiàn)的通信方式:原始套接字(sock_ram)、數(shù)據(jù)報(bào)套接字(sock_dgram)、流套接字(sock_stream)。流套接字是面向有連接的傳輸協(xié)議,能提供可靠的數(shù)據(jù)傳輸,但是頻繁的數(shù)據(jù)傳輸,會(huì)多次建立、關(guān)閉連接,消耗的時(shí)間久,影響傳輸?shù)膶?shí)時(shí)性;數(shù)據(jù)報(bào)套接字是無(wú)連接的傳輸協(xié)議,數(shù)據(jù)傳輸速度快,但是不能保證數(shù)據(jù)傳輸?shù)臏?zhǔn)確性;原始套接字能直接訪(fǎng)問(wèn)底層協(xié)議,主要應(yīng)用于一些協(xié)議的開(kāi)發(fā),功能雖然強(qiáng)大但使用較為不方便。
考慮到手持終端主要應(yīng)用于工控領(lǐng)域,應(yīng)該在保證數(shù)據(jù)準(zhǔn)確性的前提下,再去考慮數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性。因此選擇面向有連接的能提供可靠數(shù)據(jù)傳輸?shù)腡CP協(xié)議來(lái)進(jìn)行傳輸。TCP連接通信程序設(shè)計(jì)框圖如圖2所示。
2.2 TCP連接傳輸模型
圖2 TCP連接通信程序設(shè)計(jì)框圖
運(yùn)用TCP協(xié)議,正常情況下的數(shù)據(jù)包傳輸過(guò)程為:建立連接→數(shù)據(jù)傳輸→關(guān)閉連接→建立連接→數(shù)據(jù)傳輸→關(guān)閉連接→……→關(guān)閉連接,傳輸模型如圖3所示:
圖3 TCP傳輸模型
由圖3可以看出,每次數(shù)據(jù)傳輸,TCP協(xié)議都要建立連接和關(guān)閉連接。每次TCP建立連接需要3次握手才能建立成功,對(duì)實(shí)時(shí)性要求高的場(chǎng)合,這種傳輸方式太浪費(fèi)時(shí)間。若一次連接建立成功后,每次數(shù)據(jù)傳輸完成都不再關(guān)閉連接,下次若有數(shù)據(jù)包需要發(fā)送時(shí),則不用再建立和關(guān)閉連接,而是直接進(jìn)行數(shù)據(jù)包發(fā)送。這樣就可以避免中間環(huán)節(jié)頻繁建立和關(guān)閉連接消耗大量時(shí)間,傳輸速度因此會(huì)提高很多,實(shí)時(shí)性得到很大改善。
根據(jù)上述分析,若建立這樣的連接后,不主動(dòng)人為關(guān)閉它,則認(rèn)為如果沒(méi)有特殊情況影響,其會(huì)一直處于連接狀態(tài)。但是在實(shí)際應(yīng)用中,若服務(wù)器與客戶(hù)端在一段時(shí)間內(nèi)沒(méi)有傳輸數(shù)據(jù)時(shí),其連接可能會(huì)變成“休眠”狀態(tài),甚至斷開(kāi);其次,中間節(jié)點(diǎn)若出現(xiàn)什么故障也是難以知道的,造成用戶(hù)不能及時(shí)地發(fā)現(xiàn)和解決問(wèn)題。若出現(xiàn)上述兩種狀況,用戶(hù)的狀態(tài)就可能得不到實(shí)時(shí)有效的更新,造成的損失也是無(wú)法預(yù)知的。因此,如果想維護(hù)、檢測(cè)連接,則需要在服務(wù)器和客戶(hù)端制定一個(gè)通訊協(xié)議。每隔一定時(shí)間,若沒(méi)有數(shù)據(jù)傳輸,則由一方發(fā)起,向?qū)Ψ桨l(fā)送數(shù)據(jù)包。若對(duì)方收到這個(gè)數(shù)據(jù)包,則按指定好的通訊協(xié)議回一個(gè)數(shù)據(jù)包;若發(fā)起方?jīng)]有收到回復(fù),則判斷網(wǎng)絡(luò)出現(xiàn)問(wèn)題,服務(wù)器可及時(shí)地?cái)嚅_(kāi)連接,客戶(hù)端也可以及時(shí)得到重連的機(jī)會(huì),這樣的協(xié)議類(lèi)似于心跳機(jī)制。
3.1 心跳原理分析
心跳模型旨在讓客戶(hù)端和服務(wù)器獲取對(duì)方的連接狀態(tài),以保證連接正常,順利進(jìn)行通信服務(wù)。
常規(guī)的心跳機(jī)制有2個(gè)特征。特征一,它像心跳一樣每隔固定時(shí)間發(fā)一次,服務(wù)器收到心跳包后,返回給客戶(hù)端一個(gè)數(shù)據(jù)包,客戶(hù)端若在規(guī)定的時(shí)間內(nèi)沒(méi)有收到該心跳數(shù)據(jù)包,則判斷為連接斷開(kāi),通信異常。特征二,心跳協(xié)議數(shù)據(jù)包的主動(dòng)發(fā)送方既可以是服務(wù)器,也可以是客戶(hù)端,但考慮到易操作性和效率,選擇客戶(hù)端作為主動(dòng)發(fā)送方,給服務(wù)器發(fā)送心跳包。
通過(guò)上述了解可知,心跳旨在維護(hù)連接、檢測(cè)連接狀態(tài)。在傳輸數(shù)據(jù)很頻繁的時(shí)間段,這種心跳機(jī)制(特征一)就沒(méi)有必要了,而且還會(huì)占用帶寬,降低網(wǎng)絡(luò)通信效率。因此,本文將在此心跳機(jī)制的基礎(chǔ)上,修改原有心跳機(jī)制的弊端。若一段時(shí)間內(nèi)有數(shù)據(jù)傳輸時(shí),就取消心跳包的發(fā)送,不再像原有的機(jī)制那樣每隔固定時(shí)間發(fā)送。下面將詳細(xì)介紹具體的實(shí)現(xiàn)過(guò)程。
3.2 心跳包模型實(shí)現(xiàn)
出于上述這些因素的考慮,可以設(shè)計(jì)如下的心跳機(jī)制。當(dāng)本次數(shù)據(jù)發(fā)送完畢后,立刻啟動(dòng)一個(gè)超時(shí)定時(shí)器,若在定時(shí)時(shí)間到期之前有數(shù)據(jù)傳輸時(shí),則關(guān)閉超時(shí)定時(shí)器,不再額外發(fā)送心跳數(shù)據(jù)包;如果在定時(shí)時(shí)間到期之前沒(méi)有發(fā)生有效的數(shù)據(jù)傳輸,客戶(hù)端發(fā)送一個(gè)心跳包給服務(wù)器,此時(shí)根據(jù)網(wǎng)路的不同狀況,會(huì)出現(xiàn)網(wǎng)絡(luò)正常連接、網(wǎng)絡(luò)異常連接兩種情況。如果網(wǎng)絡(luò)正常連接,客戶(hù)端向服務(wù)端發(fā)起心跳包,服務(wù)端收到心跳包后立刻向客戶(hù)端發(fā)出ACK心跳回復(fù)包??蛻?hù)端收到ACK心跳回復(fù)包后,超時(shí)定時(shí)器清零重新開(kāi)始計(jì)時(shí),如果總線(xiàn)還是處于空閑狀態(tài),將進(jìn)行下一次的循環(huán)。如果網(wǎng)絡(luò)連接異常,客戶(hù)端向服務(wù)端發(fā)起心跳包,在定時(shí)時(shí)間內(nèi)服務(wù)器端沒(méi)收到心跳包,客戶(hù)端再次發(fā)出ACK心跳包,客戶(hù)端連續(xù)發(fā)送2次心跳包后服務(wù)端若還沒(méi)收到ACK心跳包,則給出連接中斷信息并進(jìn)行報(bào)警提示,進(jìn)行重新連接。
在上述內(nèi)容的基礎(chǔ)上,心跳程序模型設(shè)計(jì)可按圖4所示的流程實(shí)現(xiàn):
圖4 心跳模型程序設(shè)計(jì)
3.3 心跳機(jī)制下TCP連接傳輸模型
實(shí)現(xiàn)上述心跳模型后,在超時(shí)定時(shí)器的規(guī)定時(shí)間段內(nèi)沒(méi)有數(shù)據(jù)通信時(shí),定時(shí)發(fā)送數(shù)據(jù)包(心跳),以維持連接狀態(tài)。數(shù)據(jù)傳輸?shù)倪^(guò)程如下:建立連接→數(shù)據(jù)傳輸→保持連接(心跳)→數(shù)據(jù)傳輸→保持連接(心跳)→數(shù)據(jù)傳輸→……→關(guān)閉連接,TCP簡(jiǎn)化傳輸模型如圖5所示:
圖5 TCP簡(jiǎn)化傳輸模型
通過(guò)和圖3比較,此連接一旦建立,中間就不再關(guān)閉。再次傳輸時(shí),不用建立TCP連接,也就不需要握手過(guò)程,避免了頻繁建立連接和關(guān)閉連接消耗時(shí)間的問(wèn)題,加快了后續(xù)請(qǐng)求的響應(yīng)時(shí)間,提高了系統(tǒng)的實(shí)時(shí)性。
當(dāng)前開(kāi)發(fā)的大部分客戶(hù)端應(yīng)用,基本上都需要和服務(wù)器進(jìn)行交互,即上傳數(shù)據(jù)到服務(wù)器的同時(shí)從服務(wù)器上獲取數(shù)據(jù)。一般情況下,客戶(hù)端與服務(wù)器之間進(jìn)行通訊,客戶(hù)端是主動(dòng)的,服務(wù)器不能主動(dòng)向客戶(hù)端發(fā)消息,只能被動(dòng)地等待客戶(hù)端來(lái)取消息。實(shí)時(shí)通信已經(jīng)變成了偽實(shí)時(shí),從數(shù)據(jù)的發(fā)送和接收間隔來(lái)看,會(huì)有很大程度的延遲,這種方式使數(shù)據(jù)傳輸失去了它的實(shí)時(shí)性。為了消除以上傳輸方式的弊端,讓客戶(hù)端及時(shí)收到服務(wù)端所發(fā)送的數(shù)據(jù),通信方案有:一是使用Pull(拉)的常規(guī)方式,客戶(hù)端定時(shí)向服務(wù)器發(fā)送查詢(xún)命令數(shù)據(jù),看是否有更新的信息出現(xiàn),服務(wù)器有變化或者有通知時(shí),客戶(hù)端把相應(yīng)消息取回;二是使用數(shù)據(jù)推送(Push)的方法,若服務(wù)器端有新的數(shù)據(jù)更新,就主動(dòng)推送給客戶(hù)端,這樣客戶(hù)端就能自動(dòng)地接收到消息。以上2種機(jī)制和C語(yǔ)言中的輪詢(xún)和中斷類(lèi)似,顯而易見(jiàn)Push方式的推送比Pull方式的輪詢(xún)更優(yōu)越,效率更高。
4.1 消息推送解決方案
目前推送方案有很多,但是針對(duì)具體的實(shí)際應(yīng)用,面臨的問(wèn)題還很多。比如,谷歌推出的C2DM云端推送方案,它提供服務(wù)器向應(yīng)用程序發(fā)送數(shù)據(jù)的服務(wù),該服務(wù)可以讓移動(dòng)客戶(hù)端直接與服務(wù)器進(jìn)行通信,客戶(hù)端能很快地從服務(wù)器得到更新的數(shù)據(jù)和消息通知。但該方案存在的主要問(wèn)題是C2DM需要應(yīng)用谷歌公司的服務(wù)器,涉及到安全性問(wèn)題,所以不可用。其次,國(guó)內(nèi)也有一些第三方推送平臺(tái)可供使用,但是涉及到收費(fèi)問(wèn)題、保密問(wèn)題、服務(wù)質(zhì)量問(wèn)題、擴(kuò)展問(wèn)題等,不得不使我們望而卻步。因此,我們針對(duì)實(shí)際的應(yīng)用環(huán)境,提出了自己的方案:基于可擴(kuò)展通訊和表示協(xié)議(XMPP)來(lái)開(kāi)發(fā)定制自己的數(shù)據(jù)推送機(jī)制。
XMPP是在可擴(kuò)展標(biāo)記語(yǔ)言的協(xié)議基礎(chǔ)上開(kāi)發(fā)出來(lái)的,它繼承了XML環(huán)境中靈活的發(fā)展性,具有超強(qiáng)的可擴(kuò)展性。而且,XMPP包含了針對(duì)服務(wù)器端的軟件協(xié)議,使之能與其它客戶(hù)端進(jìn)行通話(huà),這使得開(kāi)發(fā)者更容易開(kāi)發(fā)建立客戶(hù)應(yīng)用程序或給一個(gè)系統(tǒng)添加新的功能,用于即時(shí)通訊(IM)以及在線(xiàn)探測(cè)。
利用XMPP協(xié)議的這些特性,設(shè)計(jì)了一個(gè)輕量級(jí)、簡(jiǎn)單實(shí)用的消息推送組件。原理如下:從一個(gè)客戶(hù)端到另一個(gè)客戶(hù)端的所有消息和數(shù)據(jù)都要通過(guò)XMPP服務(wù)器,在客戶(hù)端連接服務(wù)器時(shí),服務(wù)器則運(yùn)用自身的目標(biāo)機(jī)注冊(cè)信息系統(tǒng)對(duì)其進(jìn)行注冊(cè)認(rèn)證;在數(shù)據(jù)傳輸過(guò)程中客戶(hù)端指定目標(biāo)地址后,服務(wù)器根據(jù)指定的目標(biāo)地址在注冊(cè)信息系統(tǒng)查找到目標(biāo)機(jī)信息,然后把該目標(biāo)機(jī)狀態(tài)信息通知給即將發(fā)送數(shù)據(jù)的客戶(hù)端;判斷連接并進(jìn)行相互認(rèn)證后,若連接正常,客戶(hù)端之間就可以進(jìn)行數(shù)據(jù)交互,若連接失敗,則進(jìn)行提示,不再發(fā)送數(shù)據(jù),重新認(rèn)證連接正常后再發(fā)送,這樣既能保證數(shù)據(jù)不丟失,又不至于發(fā)錯(cuò)數(shù)據(jù)。
消息推送組件由服務(wù)器部分和客戶(hù)端部分組成,每一部分都由XMPP協(xié)議組件和外部接口組件構(gòu)成。XMPP協(xié)議組件負(fù)責(zé)服務(wù)器和客戶(hù)端間的連接管理、消息通訊。外部接口組件負(fù)責(zé)接收應(yīng)用系統(tǒng)、客戶(hù)端應(yīng)用的命令,向應(yīng)用系統(tǒng)發(fā)送接收到的通知消息。消息推送設(shè)計(jì)與實(shí)現(xiàn)原理模型如圖6所示:
圖6 消息推送設(shè)計(jì)與實(shí)現(xiàn)原理模型
此消息推送組件在服務(wù)器端具備消息存儲(chǔ)、消息重發(fā)等功能。在客戶(hù)端部分具備斷線(xiàn)重連、收到確認(rèn)、閱讀確認(rèn)、消息發(fā)送、命令執(zhí)行等功能,確保消息能夠推送到客戶(hù)端,同時(shí)也保證客戶(hù)端能夠收到并閱讀消息??蛻?hù)端應(yīng)用和消息推送組件完全分離,通過(guò)接口相互調(diào)用,實(shí)現(xiàn)模塊應(yīng)用的最優(yōu)化,系統(tǒng)集成簡(jiǎn)單,無(wú)需復(fù)雜的設(shè)置。
本文針對(duì)工業(yè)移動(dòng)終端的應(yīng)用背景,系統(tǒng)地分析了socket通信中的一些特性。提出了一種用于維護(hù)連接的心跳機(jī)制,并運(yùn)用XMPP協(xié)議實(shí)現(xiàn)了一種輕量級(jí)服務(wù)器和客戶(hù)端推送模型。詳細(xì)介紹了設(shè)計(jì)原理和具體實(shí)現(xiàn)流程。運(yùn)用上述2種方案,系統(tǒng)在數(shù)據(jù)傳輸時(shí),客戶(hù)端給服務(wù)器發(fā)送數(shù)據(jù),服務(wù)器給客戶(hù)端推送數(shù)據(jù),可實(shí)時(shí)收發(fā)信息。當(dāng)長(zhǎng)時(shí)間沒(méi)有數(shù)據(jù)通信時(shí),服務(wù)器和客戶(hù)端會(huì)發(fā)送保持連接的心跳數(shù)據(jù)包,同時(shí)避免了“假在線(xiàn)”或連接“休眠”狀態(tài)并能及時(shí)更新用戶(hù)狀態(tài)。
[1] 陳磊,馮冬芹,金建祥. 以太網(wǎng)在工業(yè)應(yīng)用中的實(shí)時(shí)特性研究[J]. 浙江大學(xué)學(xué)報(bào), 2004,38(6): 670-675.
[2] 羅湘平. 基于工業(yè)以太網(wǎng)的智能控制器設(shè)計(jì)[D]. 大連:大連海事大學(xué), 2011.
[3] 李慧,劉星橋,李景,等. 基于物聯(lián)網(wǎng)Android平臺(tái)的水產(chǎn)養(yǎng)殖遠(yuǎn)程監(jiān)控系統(tǒng)[J]. 農(nóng)業(yè)工程學(xué)報(bào), 2013(13): 175-181.
[4] 宋寶,姚軍,楊勇泉. 數(shù)控機(jī)床遠(yuǎn)程監(jiān)控平臺(tái)開(kāi)發(fā)和實(shí)現(xiàn)[J]. 組合機(jī)床與自動(dòng)化加工技術(shù), 2012(12): 79-81.
[5] 梁田. 融合移動(dòng)支付平臺(tái)中前置系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京: 北京郵電大學(xué), 2013.
[6] 王浩亮,白晨明. 基于一卡通系統(tǒng)的校安平臺(tái)建設(shè)[J]. 數(shù)字技術(shù)與應(yīng)用, 2013(6): 114-114.
[7] 龐國(guó)明. Android推送服務(wù)的應(yīng)用開(kāi)發(fā)[J]. 電腦編程技巧與維護(hù), 2013(19): 51-55.
[8] 楊杰. 基于A(yíng)ndroid平臺(tái)的校園新聞客戶(hù)端的設(shè)計(jì)與研發(fā)[J]. 現(xiàn)代計(jì)算機(jī), 2013(7): 64-88.
[9] 于少山,卡米力,毛依丁. 基于XML的即時(shí)通信系統(tǒng)的研究與實(shí)現(xiàn)[J]. 重慶郵電大學(xué)學(xué)報(bào): 自然科學(xué)版, 2007(B06): 59-61.★
王銀:碩士就讀于寧波大學(xué),研究方向?yàn)橐苿?dòng)通信在嵌入式系統(tǒng)的應(yīng)用、現(xiàn)場(chǎng)總線(xiàn)通信。
俞建定:碩士研究生導(dǎo)師,寧波大學(xué)副教授,主要研究方向?yàn)榍度胧较到y(tǒng)應(yīng)用、現(xiàn)場(chǎng)總線(xiàn)通信研究應(yīng)用、移動(dòng)設(shè)備的技術(shù)研究和產(chǎn)品開(kāi)發(fā)。
王新彪:碩士就讀于寧波大學(xué),研究方向?yàn)橐苿?dòng)通信在嵌入式系統(tǒng)的應(yīng)用、現(xiàn)場(chǎng)總線(xiàn)通信。
Communication Design of Handheld Terminal in Industrial Application
WANG Yin, YU Jian-ding, WANG Xin-biao, WAN Xu-dong
(Faculty of Electrical Engineering and Computer Science, Ningbo University, Ningbo 315211, China)
On the background of handheld terminal fi eld application in industrial application, a method in which heartbeat packet can be sent and socket long connection can be established was proposed according to the bad real-time of traditional Ethernet in industrial communication. It can reduce the time consumed by frequently establishing and closing connections. XMPP protocol is adopted to realize the lightweight, easily practical message push component. Because message can be pushed to server by means of the protocol, the traditional polling mechanism in server is eliminated. The proposed method can reduce response time and enhance the system real-time.
handheld terminal socket heartbeat packet message push real-time
10.3969/j.issn.1006-1010.2015.07.014
TP393
A
1006-1010(2015)07-0066-05
王銀,俞建定,王新彪,等. 工業(yè)手持終端的通信設(shè)計(jì)[J]. 移動(dòng)通信, 2015,39(7): 66-70.
2014-12-30
責(zé)任編輯:劉妙 liumiao@mbcom.cn