基于P2P結構的即時通信系統的設計與實現

張玨

（榆林學院 信息學院，陜西 榆林 719200）

隨著網絡帶寬的不斷增長，人們的通訊已經開始從以文本為主導輔助以少量的音頻和視頻信息的模式逐漸轉向以給人們更為豐富信息的音頻為主導并輔助以少量的文本和視頻信息的模式。在一些特定的場合單純的視頻通訊的需求亦隨著網絡帶寬的增長逐漸浮出水面。MSN和QQ無法滿足以上需求，市場上少量相關產品亦無法滿足網絡帶寬增長所引發的層出不窮的需求。即時通信支撐系統是在以上需求驅動之下構思的一個包裝了多種基本應用的網絡應用軟件支撐平臺，其中包括視頻采集、視頻壓縮、視頻傳輸、音頻采集、音頻壓縮、音頻傳輸、文本傳輸等。這些基本應用具有簡單的上層接口，使得基于此系統的網絡應用軟件開發人員只需了解它們的借口而不必理解其內部邏輯即可開發出各種功能強大的網絡應用軟件，可以極大的加速網絡應用軟件的開發速度。

1 總體設計

即時通信系統主要實現以下功能：

1）在局域網中兩臺或者兩臺以上的主機可以輸入對方的IP地址請求連接。

2）系統啟動視頻，音頻或文本傳輸設備。

3）遠端可以隨時終止或者開啟本地視頻，音頻等其它設備。

文本交流功能：文本交流是實現多種媒體交互的基本功能部分。本系統實現了局域網P2P文本聊天功能，主要包括：在信息欄輸入交談的內容，按發送鍵發送、同時能在聊天記錄上接收到對方的聊天內容。

語音交流功能：語音交流是多媒體會議最重要的部分，往往是最直接和最多表達信息量的一種方式。當用戶雙方接受請求，建立連接后，就可進入語音交流。通過菜單欄上的“音頻”菜單可以控制音量，屏蔽發送方或接收方中任意一方的消息。

視頻交流功能：視頻交流能使多媒體交互更具人性化，通過圖像的顯示，使人們之間的交流更加親切直觀。當下載本軟件連接成功后，就可以看到對方的視頻圖像。通過菜單欄上的“顯示控制”菜單可以屏蔽發送方或接收方中任意一方的視頻窗口。

圖1 音頻流程Fig.1 Audio process diagram

圖2 視頻流程Fig.2 Video process diagram

2 系統需求分析

啟動服務器，和連接用戶用例，活動圖如圖3所示。

啟動服務器，用戶點擊“文件”下拉菜單中“連接”選項，如果硬件條件不具備，系統拒絕，那么重新啟動系統，修正硬件，如果硬件滿足運行條件，系統接受請求，出現IP地址對話框，用戶在其中輸入正確IP地址，對方“拒絕”，重新選擇連接對象，重新輸入IP地址，對方“接受”，那么雙方鏈接成功，雙方進入交流主界面，其他功能正常啟動。

3 系統的設計與實現

主要論述了即時通信系統錄放音功能的設計與實現、采集功能的設計實現，以及發送接收系統的設計與實現。本系統是基于局域網的P2P網絡結構的即時通信系統，所以涉及到的通信雙方，不管是請求方或是被請求方，都是對等的，權限都是相同的，所有系統的使用者，都是普通用戶。所以系統只有兩個角色，即兩個類，一個普通用戶類，一個系統類。

圖3 系統活動圖Fig.3 System active diagram

一個類是系統資源，用戶類主要屬性：角色碼、用戶名、所在的IP地址。用戶操作主要有：連接服務器、視頻交流、文本交流、音頻交流。另一個類是系統資源類，為系統提供功能，主要有3個子類：音頻、視頻、文本類。音頻類主要操作為音量控制、發送、接收、播放、錄音。視頻類的主要操作有、本地視頻窗口、遠程視頻窗口。文本類，主要操作是文本交流。

3.1 語音采集與回放系統設計

音頻采集：打開錄音設備，采集發言者語音信息，是windows通過高級音頻函數、媒體控制接口MCI設備驅動程序，低級音頻函數MIDI Mapper、低級音頻設備驅動，以及DirectSound提供了音頻服務，可以從聲卡獲取音頻流。在本系統中，采用低層音頻服務來實現。

低層音頻服務主要包括查詢音頻設備、打開/關閉音頻設備驅動程序、音頻格式的設置、分配/準備音頻緩沖區以及管理音頻緩沖區等。

錄制波形音頻的流程圖如下：

1）調用函數UINT WaveInGetNumDevs：查詢系統是否具備錄制音頻的設備，函數的返回值為可進行音頻錄制的設備數量。

圖4 系統類圖Fig.4 System class diagram

由于多媒體計算機之間的音頻設備的性能差別很大，應用程序根據不同系統的音頻硬件采用不同的方法。

2）調用函數WaveInGetDevCaps（）：檢查音頻輸入設備的性能，以確定設備錄制所支持的標準音頻的格式。

如果需要錄制的是非標準格式，則需要通過調用waveInOpen函數，并設置打開設備的標志為WAVE_FORMAT_QUERY，查詢設備是否支持非標準波形格式。非標準波形格式WAVEFORMATEX說明。

3）waveInOpen函數：打開波形輸入設備。設備打開成功后，phwi將指向音頻輸入設備句柄HWAVRIN，該句柄是后續對設備進行操作的對象。

4）waveInPrepareHeader：打開音頻輸入設備，獲取句柄后，調用函數生成WAVE音頻信息頭結構。

5）waveInAddBuffer函數：將波形輸入設備獲得數據寫入WAVEHDR。

6）waveStart函數：開始錄音。

7）錄制完成后調用waceInUnPrepareHeader：清除波形音頻數據結構WAVEHDR，釋放分配的資源。

8）waveInClose：關閉波形音頻輸入設備。

需要注意的是，如果終止錄制，丟棄音頻數據塊，不能用waveInStart重新錄制。要重新錄制，必須重新準備數據塊，調用waveInReset來實現，再用waveInStart重新錄制。

3.2 語音壓縮和解壓縮的系統設計

本系統是在局域網的中進行傳輸，而且由時間等各方面的限制沒有實現語音壓縮，只是直接將采集到的語音放到緩沖區里，然后發送，最后接收方接收，但是因為沒有對語音數據進行壓縮和解壓縮，數據質量良好。

3.3 語音發送和接收的系統設計

系統利用socket中的sendto語句發送數據給接收發，接受方利用socket中的receive語句接收數據，發送時是發送緩沖區中的數據，所以接收時需要創建接收緩沖區隊列，進行接收，然后在打開放音設備，使聲音傳到人的耳朵，由于UDP協議是無連接的，每個分組都攜帶完整的目的地址，各分組在系統中獨立發送。它不能保證分組的先后順序，不進行分組出錯的恢復和重傳，因此不能保證傳輸的可靠性，但是，它提供高速率的數據報服務。由于語音聊天注重數據的實時性，所以采用UDP協議，可靠性由網絡特征來保證。實際的設計中，socket接口可以通過一個socket連接指定協議的類型，聲音數據的全雙工通訊由聲音數據的發送和接收模塊實現。系統是端對端的語音聊天功能，兩個短點之間是對等關系，對于任何一端來說，既是有客戶機的功能，同時也具備服務器的特性。語音聊天進行的是全雙工的數據通訊，對于實際通話的主叫端和客戶端都要發送數據和接收數據。從建立socket到數據的發送直至數據的接收主要有以下幾個步驟：

1）建立發送數據的soul和用于接收數據的ssine。

2）在開始時主叫端和被叫端都通過調用BIND（）函數讓soul和ssin和本地地址（包括主機地址和協議端口）聯系起來，對協議端口進行偵聽，以便接收對它服務請求產生的數據報應答。

3）為了讓系統記住發送的目的地址（即被叫端地址），在開始時，主叫端先調用CON-NECT（）函數向被叫端發出請求，然后進入發送和接收聲音數據的消息循環。

4）被叫端通過RECVFROMO函數向主叫端發出連接請求，并進入發送和接收聲音數據的消息循環。

5）在兩端建立了通訊鏈路后，就可以進行數據的雙向多次傳輸。聲音數據的發送主要有一個監聽線程和sout完成，一旦監測到有聲音信號的出現，就調用數據壓縮模塊對要發送的聲音數據進行壓縮處理，然后調用SEND（）函數把數據發送到另一端。數據的接收方同樣由一個監聽線程和ssin完成，一旦監測到有聲音數據到達，就調用RECVO函數進行接收，并把接收到的數據放入排斥區，交與聲音播放模塊處理。這樣完成了一次數據的傳輸和接收。

6）不斷重復5）的過程，直至通話結束。

主要是循環地操作nReceive和nSend指針。首先發送（接收）聲音塊的長度，然后發送（接收）聲音內容。注意：拿CSocket::Send（buffer，count）為例，其返回值（發送出去的字結數）只是1到count之間的某值，所以要添加檢測機制，否則將出現錯誤，這也是socket編程必須注意的。文中是用一個循環，直到發送出去的字節總數等于“塊”的長度才發送第二個數據塊的信息。

3.4 視頻捕獲的系統設計

視頻模塊作為視頻會議系統的一個可選的組件，強化多用戶之間的協同工作。用戶可以根據協同的需要，設備狀況或網絡通信的現狀，選擇是否進行視頻交互或調整視頻交互的質量。

在本系統中，視頻模塊主要以一定幀率捕獲視頻數據，并壓縮發送視頻數據給其他用戶，同時接收其他客戶的視頻信號，解壓縮回放視頻信號。本地視頻直接顯示并進行監控。它主要以下部分組成：

1）視頻捕獲：生成視頻捕獲窗口，捕獲視頻負責。

2）視頻發送緩沖區管理：捕獲視頻幀加入視頻發送緩沖池。

3）視頻壓縮：對視頻幀壓縮，以獲得低通信量。

4）發送視頻數據：從視頻發送緩沖池取出視頻幀在網絡信道上傳播。

5）接收視頻數據：從網絡信道接收壓縮的視頻幀。

6）視頻接收緩沖區管理：接收的視頻幀加入視頻接收緩沖池。

7）視頻解壓縮：從視頻幀接收緩沖池中取出視頻幀解壓縮。

8）視頻回放：將視頻幀在本地回放。

由于實時傳輸的需要，模塊需要在時間上并行工作，因此軟件的視頻部分由多個線程組成。線程間用事件對象進行同步，而共享數據區用臨界區對象和信號量對象進行同步。

視頻數據的實時采集主要是通過調用AVICap32.dll（avicap32.dll是Windows API應用程序接口相關模塊，用于對攝像頭和其它視頻硬件進行AVI電影和視頻的截?。﹦摻ˋVICap窗口類，由AVICap窗口類中的消息、宏函數、結構以及回調函數來完成。AVICap在捕獲視頻方面具有明顯的優勢，它能直接訪問視頻緩沖區，不需要生成中間文件，實時性很高，它也可將數字視頻保存到事先建好的文件中。實際應用表明，通過這種方法，提高了視頻采集的效果和程序運行的效率，同時也減少了對硬件的依賴性，提高了程序的兼容性和移植性。

VFW的視頻采集功能主要包括捕獲視頻流至AVI文件（capCaptureSequence）、捕獲視頻流至緩存（capCaptureSequence Nofile）、捕獲視頻流至 AVI文件（capCaptureSingleFrame）、本地預覽（capPreview/capOverlay）和捕獲單幀預覽（capGrabFrame/capGrabFrameNoStop）等。VFW還提供了回調函數，允許應用程序精確控制視頻流的捕獲、檢測錯誤、監控狀態變化 ，以及在捕獲兩幀數據的空隙和每捕獲新幀時對實時數據進行處理。

4 實驗應用

對于本系統，通過BoundsChecke軟件測試，可證明程序代碼在運行是無異常，可正常執行。在進行測試時，首先運行在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。

經過多次測試表明，該即時通信系統的各個功能都基本達到了實用的要求?！拔募毕吕藛蜗碌摹巴顺觥边x項可以隨時退出系統，“連接”選項，可以隨時選擇連接對象，客戶端能夠及時發送服務請求或視頻、音頻與文件請求，以及接收各種請求結果。在各種負荷下能正常工作，客戶端可以及時響應和處理客戶端的各種請求，沒有出現異常情況，具備一定的健壯性。局域網測試為用戶觀看到的視頻監控畫面。通過系統測試，客戶端收到的視頻圖像播放幀率在24～25幀之間波動，比服務器端滯后大約1～1.5 s，傳輸圖像較清晰，沒有出現馬賽克情況。音頻通信效果清楚，沒有出現斷音或爆音的情況，延時大約120～150 ms，能夠保證實時音頻通信。

圖5 系統測試圖Fig.5 System test diagram

5 結 論

該測試系統已用于測試用例進行測試，實際應用表明該測試系統具有測試準確、穩定可靠、人機界面友好等特點，達到了設計要求。

[1]楊云.P2P音視頻通訊系統的研究與實現[D].北京:中國地址大學，2006.

[2]伍文華.基于H.263的視頻編解碼器的研究與實現[D].武漢:華中科技大學，2007.

[3]侯俊杰.深入淺出MFC[M].2版.武漢：華中科技大學出版社，2001.

[4]王豐錦，邵新宇.基于SOCKET和多線程的應用程序間通訊技術的研究[J].計算機應用，2000（6）:65－67.WANG Feng-jing，SHAO Xin-yu.SOCKET and multithreaded applicationscommunication technology-based research[J].Computer Application，2000（6）:65－67.

[5]譚枝梅.基于TCP/IP網絡的嵌入式平臺上的視頻會議系統[D].西安:西北工業大學，2007.

[6]趙純.數字視頻采集壓縮系統實現[D].沈陽:東北大學，2008.

[7]榮治國，陳松喬.實時音頻采集、播放技術的研究[J].計算機應用研究報，2003（1）:134－135.RONG Zhi-guo，CHEN Song-qiao.Real-time audio capture[J].Applications Reported，2003（1）:134－135.