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

左憲禹+張河+王棟

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

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

中圖分類號：TP391 文獻(xiàn)標(biāo)志碼：A 文章編號：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)程會商已經(jīng)成為一種重要的交流方式，其無論從時間角度還是經(jīng)濟(jì)角度，都比傳統(tǒng)的交流方式具有優(yōu)勢。在傳統(tǒng)單一的交流方式中，往往沒法解決太多問題，很多時候會出現(xiàn)“電話里面說不清”的現(xiàn)象。所以要想真正實現(xiàn)用戶順暢的交流，必須實現(xiàn)多種方式的交流，讓用戶能從字面，圖像，視頻，語音，涂鴉板，共享文件等全方面進(jìn)行交流。因此提供一個功能多，穩(wěn)定性強(qiáng)的遠(yuǎn)程會商服務(wù)，極其符合當(dāng)前快節(jié)奏的信息交流方式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⑷ 多人會話管理

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

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

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

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

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

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

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

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

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

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

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

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

因為市面可見的NAT設(shè)備多為克隆式，且對稱式NAT無規(guī)則的分配方式較為少見，所以不作考慮。

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

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

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

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

至此，TCP連接建立完成。

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

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

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

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

3 結(jié)束語

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

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

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

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

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

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

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

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

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