移動(dòng)網(wǎng)絡(luò)下高可靠即時(shí)通信系統(tǒng)的研究與應(yīng)用

摘 要： 隨著移動(dòng)互聯(lián)網(wǎng)時(shí)代的到來，出現(xiàn)了大量?jī)?yōu)秀的即時(shí)通信軟件，其中成熟的即時(shí)通信技術(shù)都不公開，而開源的即時(shí)通信框架存在較多問題，容易出現(xiàn)丟包、消息延遲。針對(duì)上述問題，設(shè)計(jì)了移動(dòng)網(wǎng)絡(luò)下高可靠即時(shí)通信系統(tǒng)，彌補(bǔ)了開源通信框架設(shè)計(jì)中的不足，并提出對(duì)通用即時(shí)通信技術(shù)的改進(jìn)方法。首先提出了高性能通信長(zhǎng)鏈接和時(shí)間片輪轉(zhuǎn)算法，采用了消息握手協(xié)議和消息加密的方法，同時(shí)改進(jìn)了通信鏈接狀態(tài)檢測(cè)算法，并提出雙服務(wù)權(quán)限認(rèn)證方法，保證了即時(shí)通信系統(tǒng)的安全性。實(shí)驗(yàn)中測(cè)試系統(tǒng)包含了設(shè)計(jì)的即時(shí)通信框架，實(shí)驗(yàn)結(jié)果證明了系統(tǒng)的即時(shí)性和高可靠性。

關(guān)鍵詞： 即時(shí)通信； 高性能長(zhǎng)鏈接； 文件傳輸； 通信恢復(fù)機(jī)制

中圖分類號(hào)： TN911?34； TM417 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 1004?373X（2016）13?0023?04

Abstract： With the advent of the mobile Internet era， a lot of excellent instant messaging softwares appear. Since the mature instant messaging technology is unopened， and the instant messaging framework with open source exists many problems， the communication system is prone to appear packet loss and message delay. In view of the above problems， a high?reliability instant communication system in mobile network was designed to make up the deficiency of open?source communication framework design. The improved method of general instant communication technology is put forward， in which the high?performance communication long link and time slice round algorithm are proposed， the message handshake protocol and message encryption method are adopted， and the communication link state detection algorithm is improved. The double service authentication method is proposed to ensure the safety of instant messaging system. The test system in the experiment includes the designed instant messaging framework. The experimental results can prove the instantaneity and high reliability of the systemy.

Keywords： instant messaging； high?performance long link； file transfer； communication recovery mechanism

隨著移動(dòng)網(wǎng)絡(luò)的發(fā)展，網(wǎng)絡(luò)聊天、視頻和語音在網(wǎng)絡(luò)通信中越來越受重視，從網(wǎng)絡(luò)通信應(yīng)用軟件的用戶量可以看出，網(wǎng)絡(luò)即時(shí)聊天功能具有良好的用戶體驗(yàn)[1]。在新開發(fā)的各類軟件尤其是手機(jī)應(yīng)用軟件中，基本都會(huì)附帶即時(shí)通信功能。這是一種發(fā)展趨勢(shì)，網(wǎng)絡(luò)通信已經(jīng)成為了用戶溝通的重要手段，漸漸地取代了傳統(tǒng)的書信、短信等通信方式，使用的用戶越來越多，同時(shí)用戶對(duì)即時(shí)通信技術(shù)的穩(wěn)定性要求也越來越高。但由于成熟的即時(shí)通信技術(shù)不開源，而開源的即時(shí)通信技術(shù)只實(shí)現(xiàn)了基本的建立鏈接，數(shù)據(jù)傳輸并沒有做任何優(yōu)化，使得在使用過程中經(jīng)常出現(xiàn)消息延遲、消息丟失等情況[2]。

1 消息的即時(shí)傳輸

良好的用戶體驗(yàn)對(duì)即時(shí)通信系統(tǒng)的消息傳輸具有較高的要求，尤其是消息的即時(shí)性。但在某些情況下，服務(wù)器并不能即時(shí)地將信息推送給接收者，存在著兩種主要情況[3]。

（1） 客戶端與服務(wù)器之間的通信長(zhǎng)鏈接不穩(wěn)定。服務(wù)器資源限制和網(wǎng)絡(luò)問題的影響是客觀存在的，從理論的角度沒有辦法避免。但可以從其他方面解決通信鏈接的穩(wěn)定性對(duì)消息即時(shí)傳輸產(chǎn)生的影響。提出的高性能長(zhǎng)鏈接、通信鏈接的檢測(cè)和通信鏈接的恢復(fù)方法，有效地利用了服務(wù)器的資源，并保證鏈接斷開后能夠快速的恢復(fù)，從而保證消息的即時(shí)傳輸。

（2） 同一時(shí)間服務(wù)器需要推送的消息量較多。服務(wù)器轉(zhuǎn)發(fā)消息也需要消耗時(shí)間，當(dāng)同一時(shí)間進(jìn)行即時(shí)通信的用戶較多時(shí)，服務(wù)器來不及轉(zhuǎn)發(fā)新接收的消息，導(dǎo)致了消息的阻塞，從而影響了消息的即時(shí)性。因此采用消息的并發(fā)推送方法解決消息阻塞的問題[4]。

1.1 高性能通信長(zhǎng)鏈接

用戶量的不斷增加，服務(wù)器需要存儲(chǔ)的通信鏈接越來越多，但一些通信鏈接在某些時(shí)候并不會(huì)被使用。通過分析得出客戶端與服務(wù)器之間建立的通信長(zhǎng)鏈接并不會(huì)隨時(shí)都被利用，某些時(shí)間會(huì)處于空閑狀態(tài)，為此提出了高性能通信長(zhǎng)鏈接，盡量地減少客戶端空閑狀態(tài)下的鏈接時(shí)間，提高服務(wù)器的資源利用率，保證用戶量劇增時(shí)通信鏈接不會(huì)因?yàn)榉?wù)器的資源限制而斷開，從而保證消息的即時(shí)傳輸[5]。為了建立高性能通信鏈接，使用時(shí)間片輪轉(zhuǎn)的算法。把用戶開始登陸客戶端的時(shí)間或者用戶發(fā)送消息的時(shí)間記為開始時(shí)間，從開始時(shí)間起，把時(shí)間分為等長(zhǎng)的時(shí)間片段假設(shè)得到的時(shí)間片段如圖1所示。其中黑色區(qū)間表示在這個(gè)時(shí)間片段內(nèi)用戶有消息需要接收。白色的區(qū)域表示用戶處于空閑狀態(tài)沒有消息需要接收。時(shí)間片輪轉(zhuǎn)算法的目的是保證用戶使用即時(shí)通信需要接收消息時(shí)，客戶端與服務(wù)器存在通信鏈接[6]。而用戶沒有使用即時(shí)通信時(shí)，客戶端與服務(wù)器之間不存在通信鏈接，從而釋放了服務(wù)器的資源。時(shí)間片輪轉(zhuǎn)算法的規(guī)則如下：

（1） 當(dāng)客戶端需要接收消息時(shí)，當(dāng)前時(shí)間片為忙碌狀態(tài)。相反如果沒有消息需要接收，則當(dāng)前時(shí)間片處于空閑狀態(tài)。當(dāng)用戶登錄軟件后，默認(rèn)第一個(gè)時(shí)間片為忙碌狀態(tài)，并且客戶端向服務(wù)器發(fā)送建立通信鏈接的請(qǐng)求。

（2） 如果當(dāng)前時(shí)間片客戶端處于忙碌狀態(tài)，那么接下來的個(gè)時(shí)間片客戶端都將主動(dòng)向服務(wù)器端發(fā)送建立鏈接的請(qǐng)求。

（3） 如果當(dāng)前時(shí)間片的前個(gè)時(shí)間片處于空閑狀態(tài)，那么當(dāng)前時(shí)間片的鏈接狀態(tài)與前一個(gè)時(shí)間片的鏈接狀態(tài)相反。例如前一個(gè)時(shí)間片客戶端與服務(wù)器有通信鏈接，那么當(dāng)前時(shí)間片客戶端將向服務(wù)器發(fā)送斷開鏈接的請(qǐng)求。

（4） 如果當(dāng)前時(shí)間片的前個(gè)時(shí)間片中的任何一個(gè)時(shí)間片客戶端處于忙碌狀態(tài)，那么當(dāng)前時(shí)間片客戶端將向服務(wù)器發(fā)送建立鏈接的請(qǐng)求。

1.2 通信鏈接的檢測(cè)和恢復(fù)

為了保證消息的即時(shí)傳輸，提高服務(wù)器長(zhǎng)鏈接的效率，保證服務(wù)器與客戶端鏈接穩(wěn)定，避免意外中斷情況的出現(xiàn)，采用有效的長(zhǎng)鏈接檢測(cè)方法和消息恢復(fù)方法[7]。理論上稱客戶端發(fā)送詢問信息的過程為心跳過程，心跳時(shí)間指客戶端向服務(wù)器發(fā)送詢問信息的間隔時(shí)間。為了避免客戶端頻繁地發(fā)送心跳信息，消耗能量，或者避免心跳時(shí)間過長(zhǎng)，導(dǎo)致消息傳輸?shù)难舆t。本文提出了心跳時(shí)間衰減函數(shù)如下：

（1）

式中：表示第時(shí)刻的心跳時(shí)間；表示第時(shí)刻的心跳時(shí)間；和表示時(shí)間衰減系數(shù)都是常量；表示最短的心跳時(shí)間間隔，同樣也是一個(gè)常量；表示最長(zhǎng)的心跳時(shí)間間隔，也是一個(gè)常量；new表示客戶端發(fā)送了新的消息或者是服務(wù)器向客戶端推送了新的消息。心跳機(jī)制和時(shí)間片輪轉(zhuǎn)結(jié)合后，客戶端只有處于忙碌狀態(tài)時(shí)才會(huì)發(fā)送心跳信息。這樣既保證了通信鏈接的穩(wěn)定，又節(jié)約了服務(wù)器的資源。

1.3 客戶端通信恢復(fù)機(jī)制

當(dāng)客戶端啟動(dòng)后，在客戶端的后臺(tái)會(huì)啟動(dòng)兩個(gè)線程，在Android中使用Service服務(wù)，Service相當(dāng)于Activity，只是沒有界面而是運(yùn)行在后臺(tái)的服務(wù)。其中一個(gè)線程按照定時(shí)器的設(shè)定不停地向服務(wù)器發(fā)送心跳信息，確認(rèn)客戶端與服務(wù)器的通信鏈接是否正常[8]。另外一個(gè)線程用于監(jiān)聽服務(wù)器，接收服務(wù)器推送的消息。通過心跳機(jī)制，當(dāng)客戶端檢測(cè)到與服務(wù)器的通信長(zhǎng)鏈接斷開時(shí)，需要向服務(wù)器請(qǐng)求再次建立鏈接以及獲取離線數(shù)據(jù)。

為了進(jìn)一步降低服務(wù)器的數(shù)據(jù)處理壓力，提升用戶體驗(yàn)。提出了一種獲取離線消息的方法，通過短鏈接的方式獲取離線消息[9]。短鏈接指的是客戶端向服務(wù)器發(fā)送請(qǐng)求會(huì)攜帶必要的參數(shù)，而服務(wù)器做出響應(yīng)時(shí)也會(huì)把客戶端想獲取的數(shù)據(jù)返回，當(dāng)客戶端得到數(shù)據(jù)后鏈接就斷開，如圖2所示。

基于這種方式，當(dāng)客戶端與服務(wù)器的鏈接再次建立后，由客戶端主動(dòng)發(fā)送獲取離線消息的請(qǐng)求，獲取離線消息可以使用HTTP協(xié)議。客戶端不用發(fā)送確認(rèn)信息，服務(wù)器在返回信息后可以直接清除數(shù)據(jù)庫(kù)中暫存的數(shù)據(jù)，同時(shí)服務(wù)器也不用每次都對(duì)新建立的鏈接做查詢操作，這樣大大減少了服務(wù)器的壓力，同時(shí)使獲取離線消息的過程變得清晰，不會(huì)出現(xiàn)消息重復(fù)的情況。

1.4 消息并發(fā)推送

如果某一時(shí)刻發(fā)送消息的用戶較多，而服務(wù)器來不及把消息推送給目標(biāo)客戶端，那么就會(huì)造成服務(wù)器需要推送的消息越來越多，最終導(dǎo)致服務(wù)器消息的阻塞。消息阻塞雖然不會(huì)導(dǎo)致消息的丟失，但是會(huì)嚴(yán)重影響消息的即時(shí)傳輸，會(huì)給用戶帶來特別不好的使用體驗(yàn)。

為了解決這個(gè)問題，在服務(wù)器端使用了消息的并發(fā)機(jī)制。當(dāng)服務(wù)器從客戶端接收到一條新的消息后，把消息存放在本地?cái)?shù)據(jù)庫(kù)的同時(shí)也會(huì)把消息存放進(jìn)一個(gè)隊(duì)列。而在服務(wù)器的后臺(tái)，即時(shí)通信系統(tǒng)會(huì)根據(jù)服務(wù)器處理器的使用情況開啟若干個(gè)線程，每一個(gè)線程所做的操作都相同，從隊(duì)列中取出一個(gè)消息，然后根據(jù)消息中的目標(biāo)地址，查詢與其是否有通信鏈接，如果存在則把消息推送給客戶端，如果不存在則不做任何處理。這樣服務(wù)器可以在同一時(shí)間推送多條消息，有效地利用了服務(wù)器的資源，降低了消息阻塞的可能性。

2 消息的可靠傳輸

2.1 消息握手協(xié)議

為了確保消息在傳輸過程中不會(huì)出現(xiàn)丟失，提出了消息傳輸?shù)奈帐謪f(xié)議。握手協(xié)議分為客戶端給服務(wù)器發(fā)送消息的握手和服務(wù)器給客戶端推送消息的握手。握手協(xié)議的本質(zhì)是客戶端與服務(wù)器端約定的消息傳輸規(guī)則，握手的主要目的就是為了確保消息不會(huì)丟失。

（1） 正向握手協(xié)議

正向握手協(xié)議是指客戶端向服務(wù)器端發(fā)送消息時(shí)消息的確認(rèn)協(xié)議?？蛻舳诵枰l(fā)送消息時(shí)，會(huì)先把消息存放在本地?cái)?shù)據(jù)庫(kù)中，然后再調(diào)用發(fā)送消息的接口，存入本地?cái)?shù)據(jù)庫(kù)中的消息標(biāo)記為未發(fā)送。如果服務(wù)器成功接收到消息，會(huì)給客戶端返回一個(gè)包含了消息ID的反饋信息，表示自己已經(jīng)接收到消息，客戶端接收到反饋信息后，根據(jù)ID把本地?cái)?shù)據(jù)庫(kù)中的消息標(biāo)記為已經(jīng)發(fā)送，這樣就完成了一次客戶端到服務(wù)器的握手。如果沒有接收到服務(wù)器的反饋信息，那么客戶端將繼續(xù)向服務(wù)器發(fā)送這條消息。

（2） 反向握手協(xié)議

反向握手協(xié)議指的是服務(wù)器端向客戶端推送消息時(shí)消息的確認(rèn)協(xié)議。當(dāng)服務(wù)器接收到客戶端的消息后，首先會(huì)把消息存在數(shù)據(jù)庫(kù)中，然后從消息中解析出接收人的地址信息，然后根據(jù)地址信息查找目標(biāo)客戶端與自己是否有通信鏈接。

2.2 文件傳輸協(xié)議

為了避免使用通信長(zhǎng)鏈接傳輸文件，提出了文件和文件地址相分離的傳輸方法，文件存儲(chǔ)服務(wù)的提供商會(huì)提供文件上傳的相應(yīng)接口，客戶端通過調(diào)用接口，上傳文件后，會(huì)得到一個(gè)文件的網(wǎng)絡(luò)地址，通過該網(wǎng)絡(luò)地址用戶就可以直接下載文件。

3 高復(fù)用架構(gòu)

3.1 服務(wù)器

消息即時(shí)傳輸系統(tǒng)具有高復(fù)用性，就不能與應(yīng)用軟件的功能結(jié)合，本文提出了單系統(tǒng)雙服務(wù)的系統(tǒng)架構(gòu)。單系統(tǒng)指功能完全的應(yīng)用軟件系統(tǒng)，而雙服務(wù)指為應(yīng)用軟件提供了后臺(tái)服務(wù)的兩套服務(wù)系統(tǒng)：消息的即時(shí)通信系統(tǒng)和數(shù)據(jù)功能處理系統(tǒng)。這樣把消息和軟件功能分離后，就可以使消息的即時(shí)傳輸服務(wù)在任何應(yīng)用軟件中使用，其功能模塊如圖3所示。

為了保證消息后臺(tái)服務(wù)器的安全性，本節(jié)提出了雙服務(wù)權(quán)限認(rèn)證的方法。為了敘述簡(jiǎn)便，把消息后臺(tái)服務(wù)器簡(jiǎn)稱為消息系統(tǒng)，而應(yīng)用軟件的數(shù)據(jù)處理服務(wù)器簡(jiǎn)稱為功能系統(tǒng)，如圖4所示。通過這種方式，不僅增加了通信系統(tǒng)的安全性，同時(shí)也做到了功能的分離，使即時(shí)通信系統(tǒng)的后臺(tái)通用性更高。

3.2 客戶端

客戶端和服務(wù)器的設(shè)計(jì)思想類似，單獨(dú)把即時(shí)通信的功能打包封裝，僅對(duì)外提供數(shù)據(jù)的操作接口，如圖5所示?？蛻舳说募磿r(shí)通信主要包含五個(gè)功能：發(fā)送建立鏈接的請(qǐng)求；發(fā)送消息；接收消息；發(fā)送心跳信息；斷開通信鏈接，用戶退出系統(tǒng)時(shí)會(huì)調(diào)用斷開通信鏈接的功能，用于釋放服務(wù)器的資源。應(yīng)用程序的客戶端添加即時(shí)通信的功能包后，只需要根據(jù)自己消息格式修改對(duì)本地?cái)?shù)據(jù)庫(kù)的操作，對(duì)外提供的接口不變[10]。

4 系統(tǒng)測(cè)試

4.1 測(cè)試系統(tǒng)介紹

測(cè)試系統(tǒng)的主要功能是用于學(xué)校老師、學(xué)生家長(zhǎng)和學(xué)生之間的溝通，為學(xué)校管理學(xué)生帶來便利。同時(shí)也包含了即時(shí)通信的功能模塊，用于用戶之間的交流溝通，發(fā)送團(tuán)隊(duì)公告信息和發(fā)送申請(qǐng)加入團(tuán)隊(duì)的申請(qǐng)信息。

應(yīng)用系統(tǒng)在添加即時(shí)通信功能時(shí)，采用了本文設(shè)計(jì)的即時(shí)通信框架。后臺(tái)使用了雙服務(wù)器設(shè)計(jì)，提供了一個(gè)獨(dú)立的消息系統(tǒng)和一個(gè)功能系統(tǒng)，兩個(gè)系統(tǒng)之間使用同一個(gè)權(quán)限緩存。消息系統(tǒng)主要負(fù)責(zé)處理與客戶端的消息通信，功能系統(tǒng)使用的是短鏈接，為客戶端提供了獲取數(shù)據(jù)的接口。客戶端加入了即時(shí)通信包，并按照自己的需求對(duì)數(shù)據(jù)存儲(chǔ)格式和數(shù)據(jù)讀取格式做了修改。

服務(wù)器的配置是2 GB內(nèi)存、雙核、2.6 GB的主頻，2 MB的網(wǎng)絡(luò)帶寬，客戶端使用Android系統(tǒng)的手機(jī)。把一個(gè)客戶端叫A，另一個(gè)客戶端叫B。

4.2 實(shí)驗(yàn)結(jié)果

測(cè)試過程中通過改變客戶端的工作狀態(tài)來模擬用戶的各種使用情況。

測(cè)試1：參數(shù)設(shè)置：客戶端A、客戶端B同時(shí)登陸系統(tǒng)，客戶端A給客戶端B發(fā)送消息。測(cè)試結(jié)果：客戶端B能正常接收到客戶端A發(fā)送的消息。

測(cè)試2：參數(shù)設(shè)置：客戶端A、客戶端B同時(shí)登陸系統(tǒng)，客戶端A和客戶端B同時(shí)給對(duì)方發(fā)送消息。測(cè)試結(jié)果：客戶端A和客戶端B都能正常接收到對(duì)方發(fā)送的消息。

測(cè)試3：參數(shù)設(shè)置：客戶端A登陸系統(tǒng)，向客戶端B發(fā)送消息?？蛻舳薆在客戶端A發(fā)送消息后，登陸系統(tǒng)。測(cè)試結(jié)果：客戶端A發(fā)送消息成功，客戶端B正常接收到客戶端A發(fā)送的消息。

通過用例測(cè)試，應(yīng)用程序中的即時(shí)通信功能在很多情況下正常使用，滿足了本文對(duì)即時(shí)通信框架功能的要求。

壓力測(cè)試中，設(shè)置3個(gè)測(cè)試參數(shù)，并發(fā)人數(shù)、每個(gè)客戶端共發(fā)送消息的條數(shù)、每?jī)蓷l消息發(fā)送的時(shí)間間隔（單位：ms）。對(duì)私人聊天、群聊天和發(fā)送通知進(jìn)行了壓力測(cè)試，消息發(fā)送和接收的成功率都在100%。但也有消息發(fā)送和接收不到100%，甚至有88%的成功率。通過分析可以發(fā)現(xiàn)，當(dāng)消息發(fā)送成功率不高時(shí)，客戶端的在線人數(shù)和發(fā)送消息的量普遍偏高，發(fā)送消息的頻率也較快，而且發(fā)送成功率和這幾個(gè)參數(shù)之間還有反比的關(guān)系。

因此可以得出結(jié)論，當(dāng)消息發(fā)送成功率過低時(shí)，可能是受到了服務(wù)器硬件資源的限制。因?yàn)樵诰€人數(shù)過多時(shí)，客戶端需要和服務(wù)器建立的通信長(zhǎng)鏈接較多，如果同時(shí)還有多人發(fā)送群信息或者公告，那么服務(wù)器的資源將被消耗殆盡。因而會(huì)有一些通信鏈接中斷或者消息被阻塞。

5 結(jié) 論

即時(shí)通信是網(wǎng)絡(luò)聊天的核心技術(shù)，本文從消息即時(shí)傳輸、消息可靠傳輸和高復(fù)用框架三個(gè)方面對(duì)現(xiàn)在的即時(shí)通信提出了改進(jìn)方案。文中高性能通信長(zhǎng)鏈接有效地解決了普通通信長(zhǎng)鏈接消耗資源的問題，并且消息傳輸效果并不會(huì)比普通通信長(zhǎng)鏈接差。同時(shí)，在通信鏈接的檢測(cè)方法中提出了一個(gè)更加節(jié)約資源的心跳算法。加入了更高效的文件傳輸，利用第三方文件服務(wù)使文件傳輸更加可靠。然后，基于高復(fù)用框架設(shè)計(jì)了即時(shí)通信框架，減少了應(yīng)用軟件開發(fā)的周期。最后通過對(duì)即時(shí)通信系統(tǒng)的功能和性能的測(cè)試，充分證明了本文設(shè)計(jì)的即時(shí)通信系統(tǒng)可靠性較高，完成了對(duì)即時(shí)通信系統(tǒng)的研究。

參考文獻(xiàn)

[1] 葛福鴻，劉曉瑩，張麗萍.基于Socket技術(shù)的即時(shí)通信軟件的設(shè)計(jì)與實(shí)現(xiàn)[J].電腦開發(fā)與應(yīng)用，2011（5）：63?65.

[2] 劇忻，苗放.基于MINA開發(fā)高性能網(wǎng)絡(luò)應(yīng)用程序[J].重慶工學(xué)院學(xué)報(bào)（自然科學(xué)版），2008，22（10）：121?125.

[3] 鄭志剛.Web服務(wù)組合執(zhí)行引擎WebJetFlow的改進(jìn)與優(yōu)化[D].長(zhǎng)沙：湖南師范大學(xué)，2008：19?25.

[4] 陳航，趙方.基于服務(wù)器推送技術(shù)和XMPP的Web IM系統(tǒng)實(shí)現(xiàn)[J].計(jì)算機(jī)工程與設(shè)計(jì)，2012（5）：12?15.

[5] ZHOU T， LU Y. Examining mobile instant messaging user loyalty from the perspectives of network externalities and flow experience [J]. Computers in human behavior， 2011， 27（2）： 883?889.

[6] ZAMAN M， ANANDARAJAN M， DAI Q. Experiencing flow with instant messaging and its facilitating role on creative behaviors [J]. Computers in human behavior， 2010， 26（5）： 1009?1018.

[7] 潘鳳，王華軍，苗放，等.基于XMPP協(xié)議和Openfire的即時(shí)通信系統(tǒng)的開發(fā)[[J].計(jì)算機(jī)時(shí)代，2011（3）：15?19.

[8] 呂東，劉小河，王鴻飛，等.基于Android的實(shí)時(shí)視頻通信研究與實(shí)現(xiàn)[J].現(xiàn)代電子技術(shù)，2014，37（1）：25?26.

[9] 王志國(guó)，侯銀濤，石榮剛，等.Android智能手機(jī)系統(tǒng)的文件實(shí)時(shí)監(jiān)控技術(shù)[J].計(jì)算機(jī)安全，2009（12）：55?56.

[10] 田源，潘晨光，丁杰.ProtocolBuffers在即時(shí)通信系統(tǒng)中的應(yīng)用研究[J].現(xiàn)代電子技術(shù)，2014，37（5）：32?34.