基于Java的遠(yuǎn)程會(huì)商系統(tǒng)的研究與實(shí)現(xiàn)

左憲禹+張河+王棟

摘 要： 通過(guò)對(duì)Java媒體框架技術(shù)的研究，結(jié)合多媒體實(shí)時(shí)通訊技術(shù)，將其應(yīng)用在遠(yuǎn)程視頻會(huì)商中，以文字、音頻、視頻、白板、文件和圖片傳輸?shù)慕换シ绞?，?shí)現(xiàn)了遠(yuǎn)程會(huì)商所需的功能。模擬面對(duì)面交流的功能，使遠(yuǎn)程交互不僅便捷而且形象具體，通過(guò)多樣性的信息傳輸，克服了傳統(tǒng)通訊方式抽象，難以表達(dá)的缺陷。多樣性的交互方式方便了用戶交流，更大程度的滿足了用戶需求。

關(guān)鍵詞： 視頻會(huì)商； 多樣性； Java； 多媒體技術(shù)

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-8228（2017）03-14-03

Abstract： The Java media framework technology is studied， and combined with the real-time multimedia communication technology， it is applied in remote video consultation， and the required function of remote consultation is realized via the interactive mode of text， audio， video， whiteboard， file and image transmission. The simulation of the functions of face to face communication makes the remote interaction not only convenient but also specific， via the diversity information transmission， the traditional communication method's defects of abstract and difficult to express are overcome. The diversity interactive mode facilitates the communication of users， and meets the needs of users better.

Key words： video consultation； diversity； Java； multimedia technology

0 引言

隨著互聯(lián)網(wǎng)的發(fā)展，遠(yuǎn)程會(huì)商已經(jīng)成為一種重要的交流方式，其無(wú)論從時(shí)間角度還是經(jīng)濟(jì)角度，都比傳統(tǒng)的交流方式具有優(yōu)勢(shì)。在傳統(tǒng)單一的交流方式中，往往沒法解決太多問題，很多時(shí)候會(huì)出現(xiàn)“電話里面說(shuō)不清”的現(xiàn)象。所以要想真正實(shí)現(xiàn)用戶順暢的交流，必須實(shí)現(xiàn)多種方式的交流，讓用戶能從字面，圖像，視頻，語(yǔ)音，涂鴉板，共享文件等全方面進(jìn)行交流。因此提供一個(gè)功能多，穩(wěn)定性強(qiáng)的遠(yuǎn)程會(huì)商服務(wù)，極其符合當(dāng)前快節(jié)奏的信息交流方式。

1 框架結(jié)構(gòu)

本系統(tǒng)采用c/s設(shè)計(jì)結(jié)構(gòu)，服務(wù)器端負(fù)責(zé)實(shí)現(xiàn)不同用戶的實(shí)時(shí)數(shù)據(jù)接發(fā)，并承擔(dān)用戶注冊(cè)，賬戶密碼驗(yàn)證，用戶信息管理等工作。用戶登錄之后，可以查找并添加感興趣的用戶成為好友，也可以創(chuàng)建一個(gè)主題好友圈組成好友群。用戶可以與其他用戶互發(fā)文字、圖片、文件，也可以與好友單人或好友群開啟視頻會(huì)商。視頻會(huì)商一般默認(rèn)給予發(fā)起人發(fā)言權(quán)限，用戶在得到發(fā)言權(quán)限之后，將可以獲得白板的使用權(quán)和發(fā)送多媒體數(shù)據(jù)包的權(quán)限，同時(shí)也允許其他用戶用搶占的方式獲取發(fā)言權(quán)限。用戶端基于Netty組件建立與服務(wù)器的聯(lián)系，實(shí)現(xiàn)圖片、文字、文件的傳輸，利用RTP（Real-time Transport Protocol）協(xié)議實(shí)現(xiàn)音頻和視頻的采集、編解碼、傳輸，利用JMF（Java Media Framework）來(lái)管理基于時(shí)間的多媒體數(shù)據(jù)的獲取、處理和播放。

2 系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)

2.1 用戶注冊(cè)認(rèn)證及相關(guān)功能的實(shí)現(xiàn)

服務(wù)器通過(guò)對(duì)數(shù)據(jù)庫(kù)的檢索，完成用戶登陸驗(yàn)證，保證新注冊(cè)的用戶不與原有用戶信息沖突，在用戶登陸成功之后，發(fā)送其儲(chǔ)存在數(shù)據(jù)庫(kù)里的離線消息，通知其他用戶新用戶上線。

我們選擇Netty框架構(gòu)建服務(wù)器，用bind方法創(chuàng)建兩個(gè)NioEventLoopGroup線程組。當(dāng)用戶發(fā)出登錄請(qǐng)求后， 其中一個(gè)NioEventLoopGroup線程組與其建立一個(gè)channel連接，另一個(gè)進(jìn)行SocketChannel網(wǎng)絡(luò)讀寫，并連接oracle數(shù)據(jù)庫(kù)檢索相關(guān)信息，在服務(wù)器的狀態(tài)表中添加新登錄用戶信息，在服務(wù)器連接列表中添加新的channel連接[1]。

服務(wù)器收到注冊(cè)消息之后，將收到的信息與數(shù)據(jù)庫(kù)原有信息進(jìn)行檢索，保證用戶名正確且不重復(fù)的前提下，為其分配一個(gè)惟一的ID，并將其注冊(cè)相關(guān)信息存入數(shù)據(jù)庫(kù)表，作為登錄的驗(yàn)證依據(jù)。

用戶可以通過(guò)檢索ID或用戶名、昵稱，尋找其他用戶，添加為好友。每一個(gè)用戶成功完成登錄驗(yàn)證后，服務(wù)器都將其加入在線列表中，并更新其他用戶的客戶端，提示好友上線。

2.2 用戶文字、圖片、白板交互，以及文件傳輸?shù)膶?shí)現(xiàn)

為了用戶之間能發(fā)送文字和圖片，我們用一個(gè)自定義類Message類定義用戶的基本屬性如ID、姓名、IP等。當(dāng)用戶發(fā)送消息時(shí)，我們創(chuàng)建一個(gè)Message對(duì)象，將要發(fā)送的文字和圖片分別賦值給content和Image熟悉。將Message對(duì)象序列化，檢索鏈接列表中對(duì)應(yīng)的channel連接發(fā)送給服務(wù)器，最終到達(dá)對(duì)應(yīng)用戶端反序列化獲取發(fā)送內(nèi)容[2]。因?yàn)镹etty是異步非阻塞的，通過(guò)Future-Listener機(jī)制，用戶可以方便的主動(dòng)獲取或通過(guò)通知機(jī)制獲得IO操作結(jié)果，既保證了通訊結(jié)果，又緩解了Java序列化CPU資源占用率高的問題。

當(dāng)用戶需要傳輸文件時(shí)，為了降低服務(wù)器負(fù)載，我們將小于1M的文件，序列化發(fā)送。對(duì)大于1M的文件，將用戶的IP和端口等連接信息傳遞給發(fā)送方，在兩個(gè)用戶之間建立鏈接。由于Netty的“零拷貝”功能，不僅避免了文件傳輸中進(jìn)行字節(jié)緩沖區(qū)的二次拷貝，而且解決了傳統(tǒng)通過(guò)循環(huán)write方式導(dǎo)致的內(nèi)存拷貝問題，使文件傳輸?shù)男时扔趥鹘y(tǒng)基于Java序列化+BIO（同步阻塞IO）的通信框架，性能提升了8倍以上。

2.3 用戶單人及群組會(huì)商的實(shí)現(xiàn)

⑴ 數(shù)據(jù)的獲取

我們利用JMF框架中的CaturnDeviceManager獲取對(duì)應(yīng)設(shè)備的CaturnDeviceInfo對(duì)象，利用Player和Processor方法捕獲攝像頭和話筒數(shù)據(jù)，利用Processor對(duì)視頻數(shù)據(jù)進(jìn)行處理[3]。JMF利用RTP協(xié)議傳輸數(shù)據(jù)，為實(shí)時(shí)數(shù)據(jù)提供了端到端的網(wǎng)絡(luò)交付服務(wù)。

⑵ 數(shù)據(jù)的傳輸

JMF架構(gòu)的Presentation類和Processing類分別提供了上傳下載多媒體數(shù)據(jù)的處理方法。通過(guò)構(gòu)建Manager、packageMessager、CaptureDeciceManager和PlugInManager四個(gè)管理器，遵循RTP和RTCP協(xié)議進(jìn)行流量控制和擁塞控制。在一個(gè)完整的RTP流傳輸中，DataSoure媒體流被處理成RTP格式，會(huì)話管理器對(duì)數(shù)據(jù)進(jìn)行管理，將一個(gè)輸出作為DataSoure進(jìn)行管理和傳輸，最終完成RTP流的傳輸[4]。

⑶ 數(shù)據(jù)的同步

在實(shí)時(shí)傳輸過(guò)程中，系統(tǒng)時(shí)間同步尤為重要。我們利用JMF提供的三個(gè)接口：Clock、Time、Duration，確保音視頻數(shù)據(jù)的同步傳輸，降低丟包率。

RTP包中的順序號(hào)可以實(shí)時(shí)計(jì)數(shù)RTP數(shù)據(jù)包，隨時(shí)記錄RTP數(shù)據(jù)包的采樣時(shí)間戳，有效降低信息包的抖動(dòng)，確保數(shù)據(jù)的同步。

⑷ 多人會(huì)話管理

多人在線時(shí)，由于可以輪流成為發(fā)言人。成為發(fā)言人的客戶端，會(huì)在短時(shí)間內(nèi)產(chǎn)生大量的多媒體數(shù)據(jù)，數(shù)據(jù)的波動(dòng)可能給服務(wù)器帶來(lái)很大的壓力。因此我們使用sessionManager管理器管理RTP傳輸，跟蹤監(jiān)控傳輸過(guò)程，及時(shí)改變RTCP的管道控制，避免出現(xiàn)卡頓現(xiàn)象，保證輪流對(duì)話的通暢。

2.4 用戶間P2P的實(shí)現(xiàn)

由于用戶之間文件傳輸和視頻傳輸，會(huì)產(chǎn)生大量流數(shù)據(jù)，服務(wù)器壓力過(guò)大。所以在文件、視頻傳輸時(shí)，如果都采用服務(wù)器轉(zhuǎn)發(fā)方式，會(huì)給服務(wù)器帶來(lái)巨大的壓力。因此需要在用戶之間嘗試建立P2P連接，減輕服務(wù)器的傳輸壓力。

然而用戶之間的P2P傳輸，不能避免的一個(gè)問題就是NAT穿透。NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）自1994年提出以來(lái)，因?yàn)槠湓谝欢ǔ潭壬辖鉀Q了IPV4地址不足，得到了廣泛的應(yīng)用。專用網(wǎng)內(nèi)部的一些主機(jī)通過(guò)NAT方法分配本地IP地址（即僅在本專用網(wǎng)內(nèi)使用的專用地址），并利用同一個(gè)公共IP地址與外網(wǎng)通訊，既減少了IP地址的申請(qǐng)，又隱藏了內(nèi)部網(wǎng)絡(luò)構(gòu)成，增加了安全性。

因?yàn)镹AT的如上優(yōu)點(diǎn)，其得到了廣泛應(yīng)用，與此同時(shí)，大量?jī)?nèi)網(wǎng)用戶共享一個(gè)公網(wǎng)IP，這給用戶之間P2P的建立帶來(lái)巨大的困擾。由于TCP連接需要確定雙方的IP地址和端口號(hào)，而處于內(nèi)網(wǎng)的用戶是通過(guò)NAT 自動(dòng)分配獲得一個(gè)公網(wǎng)IP的端口映射。這使得用戶之間無(wú)法通過(guò)直接獲取對(duì)方IP和端口的方式建立TCP連接[5]。

2.4.1 TCP連接的內(nèi)網(wǎng)穿透

由于NAT的內(nèi)網(wǎng)映射分為兩類：克隆式NAT和對(duì)稱式NAT。其中克隆式NAT將內(nèi)網(wǎng)中相同用戶的所有連接請(qǐng)求，都映射到相同的外網(wǎng)地址。對(duì)稱式NAT則剛好相反，給內(nèi)網(wǎng)用戶的每一個(gè)連接請(qǐng)求，都映射一個(gè)不同的地址。而且對(duì)稱式NAT對(duì)每一次連接分配映射，有兩種不同的方式：有規(guī)律的（一般為順序分配），隨機(jī)無(wú)規(guī)律的分配。

針對(duì)不同NAT類型，用如下方式判斷NAT類型。

⑴ 用客戶端端口Port連接服務(wù)器，建立TCP連接，記錄下A經(jīng)過(guò)NAT映射后的地址信息IPA。

⑵ 用客戶端端口Port+1重復(fù)1中的操作，記錄地址信息IPA'。

⑶ 判斷IPA與IPA'是否相同，則可得知NAT是克隆式，還是對(duì)稱式。

⑷ 若NAT部位克隆式，多次執(zhí)行上述操作，判斷地址是否為有規(guī)律的對(duì)稱NAT。

因?yàn)槭忻婵梢姷腘AT設(shè)備多為克隆式，且對(duì)稱式NAT無(wú)規(guī)則的分配方式較為少見，所以不作考慮。

推斷出NAT的映射方式之后，進(jìn)行如下操作。

⑴ 服務(wù)器獲取用戶雙方的外網(wǎng)映射和特殊識(shí)別信息，并發(fā)送給對(duì)方，推斷出下一次連接是分配的地址，雙方用戶分別向該地址發(fā)送SYN連接請(qǐng)求，并加入自己的特殊識(shí)別信息。由于向該地址發(fā)送過(guò)請(qǐng)求，所以當(dāng)收到SYN報(bào)文時(shí)，NAT允許其進(jìn)入內(nèi)網(wǎng)，用戶可以接收對(duì)比特殊識(shí)別信息。三次握手執(zhí)行第一步。

⑵ 通過(guò)服務(wù)器通知雙方SYN消息收到，并向?qū)Ψ綑C(jī)器發(fā)送SYN+ACK數(shù)據(jù)包，并向服務(wù)器發(fā)送特殊字符P，并將P轉(zhuǎn)發(fā)給對(duì)方。

⑶ 收到P字符后停止SYN+ACK數(shù)據(jù)包發(fā)送，產(chǎn)生ACK信息并加入標(biāo)識(shí)符和特殊識(shí)別信息，反復(fù)向最新的公網(wǎng)地址發(fā)送，直至連接成功。

至此，TCP連接建立完成。

2.4.2 UDP連接的內(nèi)網(wǎng)穿透

UDP連接相對(duì)于TCP連接要簡(jiǎn)單，與TCP連接類似，UDP連接對(duì)于對(duì)稱無(wú)規(guī)則的NAT分配方式無(wú)效。在操作過(guò)程中，UDP只需要進(jìn)行一次操作，即通過(guò)服務(wù)器轉(zhuǎn)發(fā)雙方客戶端消息，雙方客戶端互發(fā)消息進(jìn)行NAT打洞操作。因?yàn)閁DP的操作相對(duì)簡(jiǎn)單，目前大多是NAT穿透，均用此方法完成。

2.4.3 服務(wù)器轉(zhuǎn)發(fā)

在上述方法均無(wú)法連接的情況下，如果服務(wù)器允許，可以用服務(wù)器轉(zhuǎn)發(fā)的方式完成傳輸。但這會(huì)加大服務(wù)器帶寬的壓力，應(yīng)當(dāng)盡量避免采用。

3 結(jié)束語(yǔ)

本文用Java多媒體技術(shù)框架，成功實(shí)現(xiàn)了遠(yuǎn)程視頻會(huì)商，能提供穩(wěn)定的會(huì)話和文件的P2P傳輸，有白板書寫功能，基本實(shí)現(xiàn)了遠(yuǎn)程會(huì)商所需要達(dá)到的效果。通過(guò)多媒體通訊很好的解決了跨區(qū)域交流的不便，利用日益發(fā)展的互聯(lián)網(wǎng)技術(shù)，提供更好的用戶體驗(yàn)，不僅可以減少交流成本，更能節(jié)省寶貴的差旅時(shí)間，讓面對(duì)面才能講清楚的問題，在網(wǎng)上也能講清楚。

隨著網(wǎng)絡(luò)帶寬的拓展，以及遠(yuǎn)程辦公需求的增多，開發(fā)多功能跨平臺(tái)的多媒體通訊應(yīng)用是大勢(shì)所趨。在此背景下，多媒體通訊的施展空間將會(huì)越來(lái)越大，在此基礎(chǔ)上不斷完善功能，提供一個(gè)持續(xù)穩(wěn)定，體驗(yàn)良好的通訊系統(tǒng)符合時(shí)代的要求。而且本系統(tǒng)具備Java跨平臺(tái)的特點(diǎn)，具備很高的可移植性，能很好地適應(yīng)以后的發(fā)展需要。

本系統(tǒng)在已完成的基礎(chǔ)上，還有很多可以完善和改進(jìn)的地方，如文檔的在線傳閱、修改，共享電子白板的圖片等共享，如果加以改進(jìn)和開發(fā)，可以為用戶提供更好的使用體驗(yàn)。

參考文獻(xiàn)（References）：

[1] 陳立定，陳偉欣.基于JMF的實(shí)時(shí)視頻組播系統(tǒng)的研究[J].微計(jì)算機(jī)信息，2009.12.

[2] 閆改珍，師衛(wèi).基于RTP的音頻流多播系統(tǒng)的JMF實(shí)現(xiàn)[J].科技情報(bào)開發(fā)與經(jīng)濟(jì)，2007.5.

[3] 吳來(lái)群.多媒體技術(shù)在企業(yè)宣傳中的應(yīng)用[J].現(xiàn)代國(guó)企研究，2016.6.

[4] 曹津，陳軍.基于用戶體驗(yàn)的多媒體教學(xué)設(shè)施預(yù)約服務(wù)系統(tǒng)研究[J].中國(guó)教育信息化，2016.8.

[5] 張連堂，嚴(yán)運(yùn)廣.集群節(jié)點(diǎn)連接信息的可視化設(shè)計(jì)[J].計(jì)算機(jī)時(shí)代，2016.2.