局域網(wǎng)語音視頻實時通信軟件開發(fā)

隨著計算機(jī)網(wǎng)絡(luò)技術(shù)的高速發(fā)展，多媒體信息通信已經(jīng)上升到了一個更高的程度-實時性。由此產(chǎn)生了一個新的名詞，實時通信。相對于傳統(tǒng)的電話、E-mail等通信方式來說，實時通信不僅節(jié)省費用，而且效率更高。

論文給出了能夠支持登陸注冊、點對點文件傳輸、視頻語音通信、多用戶聊天等功能的局域網(wǎng)實時通信系統(tǒng)的設(shè)計與實現(xiàn)。在實時通信中，特別是多媒體的實時傳輸中，對傳輸時延有非常高的要求。針對這一特點，整個系統(tǒng)采用UDP作為傳輸層協(xié)議，因而在很大程度上減少了因重傳造成的時延，同時也減輕了由此造成的網(wǎng)絡(luò)帶寬損耗。其次，設(shè)計并采用多線程和共享數(shù)據(jù)庫技術(shù)，實現(xiàn)了多用戶聊天的功能，使相互之間能夠獨立的通信。最后，在語音和視頻通信的功能的實現(xiàn)上，采用了windows系統(tǒng)提供的windowsRTC（real-timecommunication，實時通信）API。WindowsRTCAPI為任何基于MicrosoftWindowsXP的應(yīng)用程序提供了卓越的基于個人計算機(jī)的通信性能–即時消息、音頻與視頻會議、應(yīng)用程序的共享/協(xié)作。采取這樣的方法，簡化了實現(xiàn)過程，也豐富了程序的功能。

本課題以windows作為開發(fā)環(huán)境，采用C++開發(fā)工具，在相關(guān)網(wǎng)絡(luò)編程設(shè)計實例的基礎(chǔ)上，建立了能支持語音和視頻通信等功能的實時通信系統(tǒng)。關(guān)鍵詞：實時通信多線程文件傳輸語音/視頻Winsock

摘要I

ABSTRACTIII

第一章緒論1

1.1本課題研究的目的和意義1

1.2實時通信的發(fā)展及現(xiàn)狀2

1.2.1實時通信發(fā)展歷史2

1.2.2實時通信發(fā)展趨勢以及發(fā)展過程中需解決的問題4

第二章WINSOCK通信實現(xiàn)概述6

2.1WINSOCK通信原理6

2.1.1TCP和UDP6

2.1.2客戶機(jī)/服務(wù)器模式7

2.1.3WINSOCKAPI主要函數(shù)簡介8

2.1.4WINSOCK程序通信過程9

2.2多線程編程10

2.2.1線程和進(jìn)程10

2.2.2線程通信與同步11

2.3WINDOWS實時通信API12

2.4IP組播技術(shù)15

第三章局域網(wǎng)實時通信系統(tǒng)的實現(xiàn)18

3.1系統(tǒng)功能描述與模塊劃分18

3.1.1系統(tǒng)功能描述18

3.1.2系統(tǒng)模塊劃分18

3.2系統(tǒng)結(jié)構(gòu)圖19

3.3模塊功能的實現(xiàn)20

3.3.1注冊登陸模塊功能的實現(xiàn)20

3.3.2客戶端模塊功能的實現(xiàn)22

3.3.3聊天服務(wù)器模塊功能的實現(xiàn)28

3.3.4語音視頻模塊功能的實現(xiàn)30

3.3.5組播通信模塊功能的實現(xiàn)32

第四章總結(jié)與展望35

4.1實踐結(jié)果分析35

4.2展望35

致謝37

參考文獻(xiàn)37

附錄37

摘要ABSTRACT

Withthecomputernetworktechnologyhighspeeddevelops，multi-mediainfor-mationcommunicationalreadyriseshavingarrivedatahigherdegree–real-time.Fromthis,ithasproducedanewnoun–real-time-communicate.Notonlyrealtimecommunicateseconomizecost,butalsoefficiencyishigher.

Thethesishasgivenoutdesignandrealizationbeingabletosupportfunctionallocalareanetworkrealtimecommunicatesystemsuchaslandinglogon,pointtopointfiletrans-mission,video/voicecommunicate,multi-userchat.Inrealtimetransmission,especiallyinmanymediumsrealtimetransmission,ithastheverygoodrequesttotransferringtimedelay.Transferlayerofagreementsspecificallyforthisonecharacteristic,entiresystemadoptUDPtoaccomplish.Asaresulttoagreatextent,havedecreasedbythetimedelaybringingaboutbecauseofweightbiography,atthesametimealsohaslightenedthenetworkbandwidthspoilagebringingaboutfromthis.Secondly,designandadoptamulti-threadtechnologyandshareadatabase,haverealizedmulti-userchatfunction.Becauseofthistechnology,communicationisabletobeindependentbetweeneachother.Functionalrealizationinvideo/voicecommunication,commonlyusedisusesaseriesofstepsthatarethevideocapture,thevideocompression,thedatatransmission,thevideofrequencydecoding,thevideoshow.ThesystemgaveupthiscomplexwaychangetowindowsRTC(real-time-communication)APIwhichthewindowssystemprovided.Adoptedsuchmethodwhiletosimplifyrealizationprocess,therealizationresultalsoobtainedtheguarantee.

Thistopictakeswindowsasthedevelopmentenvironment,usestheVC++develop-pmentkit,inthecorrelationnetworkprogrammingdesignexamplefoundation,establish-hedhasbeenabletosupportfunctiontheandsoonpronunciationandvideocommuni-cationreal-timecommunicationsystem.

Keywords：Multi-threadreal-time-communicatefile-transmission

voice/videoWinsock

第一章緒論

1.1本課題研究的目的和意義

近十多年來電信業(yè)和互聯(lián)網(wǎng)的突飛猛進(jìn)顯然是一場行進(jìn)中的革命，它們合力推動著人類社會進(jìn)入信息和體驗經(jīng)濟(jì)時代。這場革命不僅正空前地革新著人們的通訊和溝通方式，大大提高社會生產(chǎn)與企業(yè)運作效率，而且給整個社會的諸多方面帶來深層次的影響和沖擊，導(dǎo)致了社會文化和價值觀的嬗變，引發(fā)了產(chǎn)業(yè)變革，促進(jìn)了新興行業(yè)的誕生，并帶動了相關(guān)產(chǎn)業(yè)的迅速成長。

實時通信（RTC，real-timecommunication）即是這場革命的產(chǎn)物之一。它是一種使人們能在網(wǎng)上識別在線用戶并與他們實時交換消息的技術(shù)[1]。實時通信源自ICQ。四位以色列籍年輕人在1996年7月成立了Mirabilis公司，并于同年11月推出了全世界第一個實時通信軟件ICQ（目前ICQ已經(jīng)歸AOL旗下所有），意為”我在找你”–”ISeekYou”，簡稱ICQ。典型的實時通訊是這樣工作的：當(dāng)好友列表中的某人在任何時候登錄上線并試圖通過你的計算機(jī)聯(lián)系你時，實時通訊系統(tǒng)會發(fā)一個消息提醒你，然后你能與他建立一個聊天會話并鍵入消息文字進(jìn)行交流。實時通訊被認(rèn)為比電子郵件和聊天室更具有自發(fā)性，甚至你能在進(jìn)行實時文本對話的同時一起進(jìn)行語音視頻聊天。

RTC曾經(jīng)只是眾多非常不起眼的互聯(lián)網(wǎng)應(yīng)用中的一個，因其贏利前景被認(rèn)為遙不可及，所以當(dāng)初極少有人看好RTC的發(fā)展。但是，經(jīng)過短短數(shù)年，RTC卻迅速成長為最核心的一項互聯(lián)網(wǎng)應(yīng)用，一些RTC運營商也開始源源不斷地獲得巨大經(jīng)濟(jì)收益，騰訊QQ成功的”神話”即是其中最典型的案例，更令業(yè)界大跌眼鏡的是，長大后的QQ不僅真正成了一部掙錢機(jī)器，而且似乎擁有一種神奇的魔力，無論它是出擊門戶、還是殺入網(wǎng)游，均在極短時間內(nèi)便取得巨大突破和成功，并令領(lǐng)域內(nèi)原來領(lǐng)先者們的地位岌岌可危。騰訊QQ的四處出擊、所向披靡給中國的互聯(lián)網(wǎng)業(yè)界造成了一場不小的恐慌，而恐龍級的電信運營商似乎同樣隱約感覺到了QQ們暗藏的某種殺機(jī)，也紛紛有些坐立不安了。

于是，我們見到了如下景象：各大門戶網(wǎng)站紛紛大舉進(jìn)軍RTC領(lǐng)域，電信運營商也已經(jīng)或正在謀劃推出自己的RTC服務(wù)，同時也還有許許多多來自四面八方的掘金者也滿懷希望地進(jìn)入到這塊領(lǐng)地。一時間，實時通信成了最熱鬧非凡的地帶，RTC也成了通信及互聯(lián)網(wǎng)行業(yè)最熱門的名詞之一。1.2實時通信的發(fā)展及現(xiàn)狀

1.2.1實時通信發(fā)展歷史

從1996年第一個商業(yè)化的RTC產(chǎn)品ICQ發(fā)明到2005年，RTC行業(yè)的發(fā)展可以分成三個時期[1]，即技術(shù)培育期（1996年-2000年）、產(chǎn)品應(yīng)用期（2001年-2004年）和產(chǎn)品創(chuàng)新期（2004年以后）。

1、技術(shù)培育期的RTC（1996年-2000年）

從1996年到2000年，以ICQ的出現(xiàn)為標(biāo)志，世界各地對RTC產(chǎn)品的研究和開發(fā)主要停留在技術(shù)培育期階段，在美國，AOL（美國在線）1998年6月收購了ICQ，同時自己開發(fā)了ARTC（AOLInstantMessenger）。IT業(yè)的巨頭微軟公司則于1999年7月發(fā)布了自己的RTC產(chǎn)品：MSNMessenger。而Yahoo則于1999年6月推出自己的RTC產(chǎn)品：YahooMessenger。在中國，深圳騰訊公司1999年2月推出了RTC產(chǎn)品QQ，至此RTC行業(yè)的競爭格局基本形成。

本階段的RTC產(chǎn)品處在一個突破技術(shù)瓶頸，保持RTC通訊的穩(wěn)定性為主的階段。此階段世界各國的網(wǎng)絡(luò)接入都處在撥號上網(wǎng)向?qū)拵н^渡的階段，RTC用戶經(jīng)常斷線，通訊質(zhì)量不穩(wěn)定，很多時候RTC服務(wù)器必須承擔(dān)中轉(zhuǎn)實時消息的任務(wù)，同時用戶數(shù)的爆炸性增長對于RTC系統(tǒng)的性能和效率提出了很大的挑戰(zhàn)。

2、產(chǎn)品應(yīng)用期的RTC（2001年-2004年）

2000年之后，RTC廠商的用戶圈地運動逐漸完成，各個廠商都在尋找RTC產(chǎn)品的贏利模式，他們發(fā)現(xiàn)僅僅依靠簡單的文字實時交流和在線感知功能幾乎不可能向用戶收費，事實上任何一家廠商如果對用戶注冊使用其RTC產(chǎn)品收費的話，用戶馬上就會流失到提供免費服務(wù)的競爭對手那里去，ARTC、YahooMessenger、QQ、MSN、ICQ是幾家主要的廠商，事實上各個國家還有大大小小數(shù)十家小廠商，競爭非常激烈。

為了打破這個困境，在美國MSNMessenger采取了綁定微軟自身的門戶網(wǎng)站（）的模式來贏利，用戶在MSNMessenger中就可以點擊新聞鏈接從而自動啟動系統(tǒng)默認(rèn)瀏覽器到MSN門戶網(wǎng)站進(jìn)行瀏覽，還可在MSNMessenger中輸入關(guān)鍵字提交到默認(rèn)的搜索引擎站點后啟動瀏覽器顯示搜索結(jié)果，同時為提高用戶對MSNMessenger的黏性，微軟在MSNMessenger中加入了其他更豐富的應(yīng)用：點對點的文件傳輸、視頻/音頻對話、與移動電話集成等，所有這些應(yīng)用都超出了2000年之前RTC產(chǎn)品的標(biāo)準(zhǔn)模式，使得RTC向多媒體、內(nèi)容服務(wù)和移動應(yīng)用方面發(fā)展。

同樣，YahooMessenger、QQ、ICQ和ARTC都在發(fā)展各自的客戶應(yīng)用，從大方向來看，都和MSNMessenger一樣往多媒體、內(nèi)容服務(wù)和移動應(yīng)用方面發(fā)展，但由于每家運營商的背景不同，導(dǎo)致各自的應(yīng)用重點不同，例如QQ在手機(jī)短信、移動設(shè)備方面的優(yōu)勢在全球范圍內(nèi)都比較獨特，導(dǎo)致其贏利主要來自于手機(jī)短信收費。而ARTC和ICQ由于其運營商AOL是美國最大的互聯(lián)網(wǎng)接入服務(wù)商（ISP：InternetServiceProvider），因此其收入并不直接來自RTC產(chǎn)品本身，而是通過用戶使用RTC產(chǎn)品時帶來的互聯(lián)網(wǎng)接入服務(wù)收入來贏利，YahooMessenger的贏利模式和功能特點與MSNMessenger很類似，甚至其用戶群體有相當(dāng)?shù)闹睾?，Yahoo主要是想通過YahooMessenger來提高其門戶網(wǎng)站的訪問量，而Yahoo作為美國第一大門戶站點，其贏利模式已經(jīng)比較成熟，即收入主要來源于廣告。

這個時期由于產(chǎn)品應(yīng)用開始成型，導(dǎo)致每個產(chǎn)品的業(yè)務(wù)模式逐漸固定下來，各個產(chǎn)品的用戶定位也開始逐漸清晰，如QQ在中國主要定位在30歲以下的年輕人，代表著一種時尚，而MSNMessenger在中國主要定位于辦公室中的商務(wù)人士，這直接導(dǎo)致了兩者的應(yīng)用有很大的差別。

總的來說，這段時間的RTC應(yīng)用擺脫了早期單調(diào)的文本實時通訊，開始針對不同的用戶群體開發(fā)了豐富多彩的應(yīng)用，使RTC用戶數(shù)仍然保持很高的增長速度。

3、產(chǎn)品創(chuàng)新期的RTC（2004年以后）

2004年之后，各個廠商對RTC用戶的爭奪更加激烈，同時互聯(lián)網(wǎng)上的新應(yīng)用發(fā)展速度更加快，很多功能非常具有創(chuàng)新性，并且這種創(chuàng)新性的應(yīng)用傳播速度非常之快，遠(yuǎn)遠(yuǎn)超出了傳統(tǒng)工業(yè)中新技術(shù)的擴(kuò)散速度。這些應(yīng)用當(dāng)中比較具有代表性的有博客（WebBlogger：也稱為網(wǎng)絡(luò)日志）、RSS（ReallySRTCpleSydicattion）、音樂文件共享、視頻點播（VOD：VideoOnDemand）等，為了保持用戶對RTC軟件的黏性，各個廠家都想盡辦法將這些新技術(shù)部署到新版本的RTC產(chǎn)品中去。同時，由于用戶增長速度已經(jīng)開始下降，社會上要求現(xiàn)有RTC運營商之間實現(xiàn)互聯(lián)互通的呼聲越來越高，在產(chǎn)品應(yīng)用期階段中開始討論的標(biāo)準(zhǔn)統(tǒng)一問題的解決進(jìn)度大大加快，互聯(lián)網(wǎng)上主要的標(biāo)準(zhǔn)制訂組織IETF（InternetEngineeringTaskForce）對RTC行業(yè)技術(shù)標(biāo)準(zhǔn)的討論進(jìn)入了實質(zhì)性階段。部分廠商之間的RTC產(chǎn)品已經(jīng)開始了互通的嘗試，這使得原來依靠封閉協(xié)議來保持用戶忠誠度的RTC廠商開始轉(zhuǎn)變策略，目前已經(jīng)肯定不同RTC產(chǎn)品之間的互聯(lián)互通是未來的發(fā)展方向，但具體到每個廠商，其進(jìn)度和實施策略卻由于商業(yè)利益而有很大的差異，互通性本身實際上已經(jīng)成為RTC產(chǎn)品的一個創(chuàng)新性。

本階段的另一個重點創(chuàng)新是RTC技術(shù)開始進(jìn)入企業(yè)內(nèi)部網(wǎng)（Intranet），或者稱為企業(yè)級RTC，如騰訊公司的RTX、微軟公司的LCS、AOL的EnterpriseARTC等，這直接導(dǎo)致了RTC的應(yīng)用向企業(yè)級軟件層次發(fā)展。另一個重要的發(fā)展是人們對RTC產(chǎn)品的安全性開始重視起來，特別是2004年幾次大的計算機(jī)病毒流行都是通過QQ、MSNMessenger等RTC產(chǎn)品傳播，使不少企業(yè)禁止在內(nèi)部網(wǎng)絡(luò)中使用RTC軟件，但這也導(dǎo)致RTC安全管理軟件市場開始興起，國外不少公司開始專門開發(fā)產(chǎn)品管理企業(yè)內(nèi)部的RTC應(yīng)用。

1.2.2實時通信發(fā)展趨勢以及發(fā)展過程中需解決的問題

由于實時通信軟件的興起，能夠進(jìn)行實時互通的”內(nèi)容”正迅速由語音全面擴(kuò)展到圖像、文字、數(shù)據(jù)等方面，它給我們的生活帶來了翻天覆地的變化。不過”多功能”還不是實時通信的全部內(nèi)涵，能夠跨越互聯(lián)網(wǎng)、手機(jī)、固定電話等多個平臺進(jìn)行通信才是實時通信未來的價值所在。一位業(yè)內(nèi)人士認(rèn)為，實時通信已經(jīng)跨越原來狹義上的”網(wǎng)絡(luò)”概念，正向更為廣義的方向發(fā)展，未來的實時通信軟件可以讓我們隨時隨地和任何人進(jìn)行任何方式的溝通，不僅是語音，還包括圖像、資料、數(shù)據(jù)等等，不僅在電腦上，還可以在手機(jī)、固定電話等任何終端上。但是，我們應(yīng)該看到，同其他的互聯(lián)網(wǎng)應(yīng)用一樣，實時通信原本是電腦玩家的寵物，一旦上升到商務(wù)層面，其發(fā)展面臨的問題便日漸突出，其中安全和互聯(lián)互通便是當(dāng)前實時通信發(fā)展的軟肋。這也是未來實時通信軟件進(jìn)一步發(fā)展的趨勢。

實際上，實時通信軟件之間要實現(xiàn)互聯(lián)互通將主要涉及到技術(shù)和利益兩個方面：

在技術(shù)上，實時通信軟件之間互聯(lián)互通的技術(shù)操作難度并不高，軟件之間實現(xiàn)兼容、實現(xiàn)互聯(lián)互通完全可以做到。去年9月，美國路透社、AOL就簽署了一項合作協(xié)議以實現(xiàn)兩家公司的實時通信服務(wù)軟件之間的互相開放。這樣，路透社實時通信軟件的用戶將能夠”看到”登錄到包括ARTC、ICQ在內(nèi)的AOL公司實時通信服務(wù)系統(tǒng)上的用戶，并與他們互相通信。

目前互聯(lián)互通難，就難在互聯(lián)互通企業(yè)間的利益分配上。因為多數(shù)實時通信軟件的用戶，都希望通過實時通信軟件尋找網(wǎng)友實現(xiàn)網(wǎng)絡(luò)交流，當(dāng)然會首先選擇使用已經(jīng)擁有相當(dāng)多使用者的實時通信軟件。一般來說，用戶群體龐大的實時通信軟件在功能上必定已相當(dāng)完善，在程序運行上會更加穩(wěn)定，這也是許多用戶青睞QQ、MSN的主要原因。由此，”強(qiáng)者愈強(qiáng)，弱者愈弱”。而對于騰訊QQ、MSN這樣已經(jīng)擁有數(shù)百萬用戶的企業(yè)而言，他們更愿意將精力放在對自身實時通信產(chǎn)品的進(jìn)一步研發(fā)上，產(chǎn)品間的互聯(lián)互通在一定程度上會分流這些企業(yè)的潛在用戶甚至現(xiàn)有用戶。

如果能夠解決利益分配上的問題，互聯(lián)互通實現(xiàn)的就將在不遠(yuǎn)的將來。

實時通信未來的發(fā)展還有一個很重要的的就是：安全方面，無論是個人用戶，還是企業(yè)用戶，都面臨新的威脅。對于個人用戶來說，通過實時通信軟件傳播的病毒就像潛藏的炸彈，一旦爆發(fā)，輕則資料丟失，重則電腦癱瘓，更有甚者，會造成實時通信用戶之間的誤會。

而對于企業(yè)級用戶來說，一個重要問題就是大多數(shù)實時通信系統(tǒng)是公開的，這意味著用戶只要知道另一個用戶的實時通信地址，他就可以直接向?qū)Ψ桨l(fā)送信息，這對于員工向外界泄露企業(yè)的商業(yè)秘密非常便利。而且實時通信的主要特點是兩臺終端之間可以直接進(jìn)行交流，而不必通過任何第三方服務(wù)器中轉(zhuǎn)。這就使得網(wǎng)絡(luò)監(jiān)管對實時通信用戶的數(shù)據(jù)交換進(jìn)行監(jiān)控的難度增加，這讓企業(yè)管理者大為頭疼。實時通信的廣泛使用以及它本身缺乏安全功能的特性，為向它添加加密、歸檔和日志功能的產(chǎn)品創(chuàng)造出了很大需求。

不過，只要擁有龐大的用戶群，并且能夠有現(xiàn)實的商業(yè)利益，上述的兩個難題都會得到解決。最近，AOL、微軟和雅虎正相互合作讓各自的實時信息服務(wù)實現(xiàn)企業(yè)環(huán)境內(nèi)的互通，這也是這些業(yè)界領(lǐng)袖為了讓三種不同系統(tǒng)的電腦用戶相互通信的首次重大合作和突破。三巨頭將公布為打破各自網(wǎng)絡(luò)間的”電子圍墻”，讓實時通信在商務(wù)領(lǐng)域獲得更大范圍應(yīng)用的合作計劃。為了使用這種新系統(tǒng)，企業(yè)要先行獲得微軟網(wǎng)絡(luò)軟件的授權(quán)，這種軟件將會充當(dāng)連接AOL、微軟、MSN和雅虎各自運作的系統(tǒng)的網(wǎng)絡(luò)中心。

在安全方面，企業(yè)應(yīng)用的要求顯然更高。實時通信軟件為適應(yīng)用戶的需求，不斷提高系統(tǒng)的通信能力，即通過防火墻的能力，這就為安全帶來負(fù)面作用。這就要求企業(yè)必須綜合考慮防火墻、防病毒、入侵監(jiān)測、安全評估、VPN等多種產(chǎn)品，根據(jù)網(wǎng)絡(luò)的具體拓?fù)浜蛻?yīng)用的具體需求，制訂整體的解決方案和安全策略。專家建議，企業(yè)可以建置企業(yè)內(nèi)部封閉式的實時信息系統(tǒng)。所謂封閉式實時信息系統(tǒng)是在企業(yè)內(nèi)部建立自己的實時信息服務(wù)器，在每臺個人計算機(jī)上安裝特定的實時信息程序，這個程序可以是企業(yè)自己開發(fā)的，也可以是通用的，比如BQQ、MSN等。實時信息系統(tǒng)完全運作在企業(yè)的Intranet環(huán)境并不與外界有任何聯(lián)系。其優(yōu)點是可以為企業(yè)提供更為安全、可靠的音視頻文件及信息傳輸服務(wù)，同時網(wǎng)絡(luò)管理人員還可對企業(yè)內(nèi)部實時信息進(jìn)行更加有效的管理。此外，在企業(yè)內(nèi)部設(shè)置實時信息網(wǎng)關(guān)也是一種有效的途徑，每一個員工都可以使用通用的實時信息程序進(jìn)行方便、快捷的實時通信，但必須通過公司內(nèi)部的實時信息網(wǎng)關(guān)，通過實時信息網(wǎng)關(guān)對信息進(jìn)行過濾和管理，任何進(jìn)出的實時通信信息都必須留下記錄(日志文件)，必要時信息管理人員可以根據(jù)這些記錄追查來龍去脈。第二章Winsock通信實現(xiàn)概述

2.1Winsock通信原理

2.1.1TCP和UDP

1、TCP報文段格式

兩臺機(jī)器之間的TCP傳輸?shù)臄?shù)據(jù)單元叫報文段（segment）。TCP通過報文段的交互來建立連接、傳輸數(shù)據(jù)、發(fā)出確認(rèn)、通告窗口大小以及關(guān)閉連接[2]。

TCP每個報文段分為兩個部分：首部和數(shù)據(jù)。首部攜帶了所需的表示和控制信息源。端口（SOURCEPORT）和目的端口（DESTINATIONPORT）字段包含了連接兩端對應(yīng)應(yīng)用程序進(jìn)行標(biāo)識的TCP協(xié)議端口號。序號（SEQUENCENUMBER）字段指出了這個報文段在發(fā)送方的數(shù)據(jù)字節(jié)流的位置。確認(rèn)號（ACKNOWLEDGEMENTNUMBER）字段指出了本機(jī)希望接受的下一個八位組的序號。

2、UDP協(xié)議的報文格式

在TCP/IP協(xié)議族中，用戶數(shù)據(jù)報協(xié)議UDP（UserDatagramProtocol）是傳輸層上另一個重要的協(xié)議[3]。它為應(yīng)用程序之間提供面向無連接的不可靠的數(shù)據(jù)報的傳輸服務(wù)。UDP使用底層的Internet協(xié)議，在各機(jī)器之間傳輸報文，提供和IP一樣的不可靠的、無連接數(shù)據(jù)報交付服務(wù)。它是一個非常簡單的協(xié)議沒有使用確認(rèn)機(jī)制來確保報文到達(dá)，沒有對傳入的報文重新排序的功能，也不提供反饋信息來控制機(jī)器之間信息流動的速度。所以UDP的報文傳輸可能出線丟失、重復(fù)、延遲以及亂序的錯誤。

源端口（SOURCEPORT）字段和目的端口（DESTINATIONPORT）字段包含了16比特的UDP協(xié)議端口號，以便在各個等待接收報文的進(jìn)程之間對數(shù)據(jù)報進(jìn)行多路分解操作，其中源端口字段是可選的。

3、TCP和UDP的區(qū)別

在TCP/IP模型中，傳輸層介于網(wǎng)絡(luò)層和應(yīng)用層之間是一個需要在主機(jī)間實現(xiàn)高可靠性的數(shù)據(jù)包交換的網(wǎng)絡(luò)層面。為了在并不可靠的網(wǎng)絡(luò)上實現(xiàn)面向連接的可靠的傳送，數(shù)據(jù)傳輸層必須解決數(shù)據(jù)傳輸?shù)目煽啃?、流量控制以及連接問題。因此，傳輸層協(xié)議必須是一種面向連接的端到端的可靠協(xié)議。在TCP/IP模型中支持傳輸層的網(wǎng)絡(luò)協(xié)議主要有兩種：TCP協(xié)議和UDP協(xié)議。這兩種協(xié)議由于傳輸機(jī)制上的不同，向上層提供的網(wǎng)絡(luò)服務(wù)也就不同。對于應(yīng)用程序來說，必須根據(jù)應(yīng)用程序特定的服務(wù)質(zhì)量來選擇不同的傳輸層協(xié)議。

TCP提供了一個完全可靠的面向連接的傳輸服務(wù)。為了在服務(wù)器端和客戶端之間傳送TCP數(shù)據(jù)，必須首先建立一個虛擬電路，也就是建立一個TCP連接。

TCP鏈接的可靠性，它是在犧牲了鏈接速度而確保了連接的可靠性。由于TCP連接是可靠的，因而也保證了傳送數(shù)據(jù)包的順序。另外在傳送數(shù)據(jù)的過程中，TCP采用了超時重傳機(jī)制，對時延增加的響應(yīng)就是重傳數(shù)據(jù)報，從而把數(shù)據(jù)丟失率控制在一個相對小的范圍內(nèi)。但是TCP豐富的功能有時會導(dǎo)致不可預(yù)料的性能低下，當(dāng)網(wǎng)絡(luò)狀況不好時這種重傳機(jī)制可能造成大量數(shù)據(jù)需要重新傳送，從而很容易造成網(wǎng)絡(luò)擁塞現(xiàn)象的出現(xiàn)。

與TCP不同，UDP向應(yīng)用層提供的是無連接的傳輸服務(wù)。這種服務(wù)不需要通過三次握手來確保鏈路的可靠性。由于鏈路的不可靠性使得數(shù)據(jù)傳輸變得不可靠，也不能夠保證數(shù)據(jù)報按順序地遞交。但是UDP的重要特點是協(xié)議的開銷小，因此，在很多場合中還是相當(dāng)實用的。

通過對TCP和UDP介紹和比較，針對本文所涉及的多媒體數(shù)據(jù)實時通信系統(tǒng)而已，首先需要選擇哪種傳輸層協(xié)議作為多媒體實時通信的傳輸方式。很明顯，在需要強(qiáng)調(diào)完整性和可控性時，TCP無疑是當(dāng)然的選擇。但在本文所關(guān)心的多媒體實時數(shù)據(jù)時，UDP則是最好的選擇其優(yōu)越性體現(xiàn)在如下幾點[4]：

(1)多媒體通信中，系統(tǒng)對數(shù)據(jù)包的丟失率具有一定的容忍度，對傳輸時延卻有很高的要求，系統(tǒng)不希望因為重傳數(shù)據(jù)包而增加網(wǎng)絡(luò)的傳輸時延。

(2)多媒體通信中，支持多媒體通信的一些實時傳輸協(xié)議，如RTP協(xié)議，本身已經(jīng)能夠處理流控制和順序化。所以，不需要傳輸協(xié)議進(jìn)行同樣的工作，否則，將會降低系統(tǒng)的效率。

(3)多媒體通信中，經(jīng)常用到組播Multicast機(jī)制，需要使用UDP這樣的

無連接的傳輸層協(xié)議。因為UDP能夠在實時環(huán)境中提供任意方式的通信，它不但能讓一對應(yīng)用之間進(jìn)行通信，還可以讓單個源向多個接收端進(jìn)行組播，甚至能允許任意一組應(yīng)用向任意一組接收方發(fā)送數(shù)據(jù)。用數(shù)學(xué)術(shù)語來說，UDP支持一對一、多對一、一對多以及多對多的通信方式，而面向連接的傳輸層協(xié)議不適用于這些功能。

綜上所述，針對多媒體實時數(shù)據(jù)采用UDP作為傳輸層協(xié)議很大程度上減少了因重傳造成的時延，同時也減輕了由此造成的網(wǎng)絡(luò)帶寬損耗，從而提高整個系統(tǒng)的執(zhí)行效率。

2.1.2客戶機(jī)/服務(wù)器模式

在TCP/IP網(wǎng)絡(luò)中兩個進(jìn)程間的相互作用的主機(jī)模式是客戶機(jī)/服務(wù)器模式(Client/Servermodel)。該模式的建立基于以下兩點[5]：1、非對等作用；2、通信完全是異步的。客戶機(jī)/服務(wù)器模式在操作過程中采取的是主動請示方式：

首先服務(wù)器方要先啟動，并根據(jù)請示提供相應(yīng)服務(wù)：（過程如下）

（1）打開一通信通道并告知本地主機(jī)，它愿意在某一個公認(rèn)地址上接收客戶請求。

（2）等待客戶請求到達(dá)該端口。

（3）接收到重復(fù)服務(wù)請求，處理該請求并發(fā)送應(yīng)答信號。

（4）返回第二步，等待另一客戶請求

（5）關(guān)閉服務(wù)器。

客戶方：

（1）打開一通信通道，并連接到服務(wù)器所在主機(jī)的特定端口。

（2）向服務(wù)器發(fā)送服務(wù)請求報文，等待并接收應(yīng)答；繼續(xù)提出請求……

（3）請求結(jié)束后關(guān)閉通信通道并終止。

2.1.3WinsockAPI主要函數(shù)簡介

1、創(chuàng)建套接字–socket()

功能：使用前創(chuàng)建一個新的套接字

格式：SOCKETPASCALFARsocket(intaf,inttype,intprocotol);

參數(shù)：af:通信發(fā)生的區(qū)域

type:要建立的套接字類型

procotol:使用的特定協(xié)議

2、指定本地地址–bind()

功能：將套接字地址與所創(chuàng)建的套接字號聯(lián)系起來。

格式：intPASCALFARbind(SOCKETs,conststructsockaddrFAR*name,intnamelen);

參數(shù)：s:是由socket()調(diào)用返回的并且未作連接的套接字描述符（套接字號）。

其它：沒有錯誤，bind()返回0，否則SOCKET_ERROR

地址結(jié)構(gòu)說明：

structsockaddr_in

{

shortsin_family;//AF_INET

u_shortsin_port;//16位端口號，網(wǎng)絡(luò)字節(jié)順序

structin_addrsin_addr;//32位IP地址，網(wǎng)絡(luò)字節(jié)順序

charsin_zero[8];//保留

}

3、建立套接字連接–connect()和accept()

功能：共同完成連接工作

格式：intPASCALFARconnect(SOCKETs,conststructsockaddrFAR*name,intnamelen);

SOCKETPASCALFARaccept(SOCKETs,structsockaddrFAR*name,intFAR*addrlen);

4、監(jiān)聽連接–listen()

功能：用于面向連接服務(wù)器，表明它愿意接收連接。

格式：intPASCALFARlisten(SOCKETs,intbacklog);

5、數(shù)據(jù)傳輸–send()與recv()

功能：數(shù)據(jù)的發(fā)送與接收

格式：intPASCALFARsend(SOCKETs,constcharFAR*buf,intlen,intflags);

intPASCALFARrecv(SOCKETs,constcharFAR*buf,intlen,intflags);

6、多路復(fù)用–select()

功能：用來檢測一個或多個套接字狀態(tài)。

格式：intPASCALFARselect(intnfds,fd_setFAR*readfds,fd_setFAR*writefds,

fd_setFAR*exceptfds,conststructtimevalFAR*timeout);

參數(shù)：readfds:指向要做讀檢測的指針

writefds:指向要做寫檢測的指針

7、關(guān)閉套接字–closesocket()

功能：關(guān)閉套接字s

格式：BOOLPASCALFARclosesocket(SOCKETs);

2.1.4Winsock程序通信過程

1、無連接協(xié)議的套接字調(diào)用時序圖，如圖2.1所示圖2.1無連接協(xié)議的套接字調(diào)用時序圖

2、面向連接的套接字的系統(tǒng)調(diào)用時序圖，如圖2.2所示圖2.2面向連接的套接字的系統(tǒng)調(diào)用時序圖

2.2多線程編程

2.2.1線程和進(jìn)程

進(jìn)程（Process）是具有一定獨立功能的程序關(guān)于某個數(shù)據(jù)集合上的一次運行活動，是系統(tǒng)進(jìn)行資源分配和調(diào)度的一個獨立單位[6]。程序只是一組指令的有序集合，它本身沒有任何運行的含義，只是一個靜態(tài)實體。而進(jìn)程則不同，它是程序在某個數(shù)據(jù)集上的執(zhí)行，是一個動態(tài)實體。它因創(chuàng)建而產(chǎn)生，因調(diào)度而運行，因等待資源或事件而被處于等待狀態(tài)，因完成任務(wù)而被撤消，反映了一個程序在一定的數(shù)據(jù)集上運行的全部動態(tài)過程。

線程（Thread）是進(jìn)程的一個實體，是CPU調(diào)度和分派的基本單位。線程不能夠獨立執(zhí)行，必須依存在應(yīng)用程序中，由應(yīng)用程序提供多個線程執(zhí)行控制。

線程和進(jìn)程的關(guān)系是：線程是屬于進(jìn)程的，線程運行在進(jìn)程空間內(nèi)，同一進(jìn)程所產(chǎn)生的線程共享同一內(nèi)存空間，當(dāng)進(jìn)程退出時該進(jìn)程所產(chǎn)生的線程都會被強(qiáng)制退出并清除。線程可與屬于同一進(jìn)程的其它線程共享進(jìn)程所擁有的全部資源，但是其本身基本上不擁有系統(tǒng)資源，只擁有一點在運行中必不可少的信息(如程序計數(shù)器、一組寄存器和棧)。

操作系統(tǒng)引入線程的概念還帶來了許多的好處：

（1）在進(jìn)程內(nèi)創(chuàng)建、終止線程比創(chuàng)建、終止進(jìn)程要快；

（2）同一進(jìn)程內(nèi)的線程間切換比進(jìn)程間的切換要快，尤其是用戶級線程間的切換。

另外，線程的出現(xiàn)還因為以下幾個原因：

（1）并發(fā)程序的并發(fā)執(zhí)行，在多處理環(huán)境下更為有效。一個并發(fā)程序可以建立一個進(jìn)程,而這個并發(fā)程序中的若干并發(fā)程序段就可以分別建立若干線程,使這些線程在不同的處理機(jī)上執(zhí)行。

（2）每個進(jìn)程具有獨立的地址空間，而該進(jìn)程內(nèi)的所有線程共享該地址空間。這樣可以解決父子進(jìn)程模型中，子進(jìn)程必須復(fù)制父進(jìn)程地址空間的問題。

（3）線程對解決客戶/服務(wù)器模型非常有效。

操作系統(tǒng)從單進(jìn)程單線程發(fā)展到多進(jìn)程多線程是必然的趨勢，當(dāng)年的DOS系統(tǒng)屬于單任務(wù)操作系統(tǒng)，最優(yōu)秀的程序員也只能通過駐留內(nèi)存的方式實現(xiàn)所謂的”多任務(wù)”，而如今的Win32操作系統(tǒng)卻可以一邊聽音樂，一邊編程，一邊打印文檔。

2.2.2線程通信與同步

線程之間通信的兩個基本問題是互斥和同步。

線程同步是指線程之間所具有的一種制約關(guān)系，一個線程的執(zhí)行依賴另一個線程的消息，當(dāng)它沒有得到另一個線程的消息時應(yīng)等待，直到消息到達(dá)時才被喚醒。

線程互斥是指對于共享的操作系統(tǒng)資源（指的是廣義的”資源”，而不是Windows的.res文件，譬如全局變量就是一種共享資源），在各線程訪問時的排它性。當(dāng)有若干個線程都要使用某一共享資源時，任何時刻最多只允許一個線程去使用，其它要使用該資源的線程必須等待，直到占用資源者釋放該資源[7]。

線程互斥是一種特殊的線程同步。

實際上，互斥和同步對應(yīng)著線程間通信發(fā)生的兩種情況：

（1）當(dāng)有多個線程訪問共享資源而不使資源被破壞時；

（2）當(dāng)一個線程需要將某個任務(wù)已經(jīng)完成的情況通知另外一個或多個線程時，

在WIN32中，同步機(jī)制主要有以下幾種：

（1）事件(Event);

（2）信號量(semaphore);

（3）互斥量(mutex);

（4）臨界區(qū)(Criticalsection)。

2.3Windows實時通信API

微軟實時通信（RTC）API是一套提供有豐富功能的核心組件[8]。這些性能我們可以在WindowsMessenger和其它使用實時通信API的應(yīng)用程序中看到。

MicrosoftWindowsXP中結(jié)合與增強(qiáng)了豐富的通信特性，為RTC體驗提供了基礎(chǔ)。MicrosoftWindowsMessager利用這些特性為用戶到用戶間的通信提供了實時語音和視頻、實時消息和其它的協(xié)作功能。另外，其所提供的應(yīng)用程序編程接口（APIs）使得這些豐富的通信特性可用于任何應(yīng)用程序。

1、音頻視頻編解碼器的可獲得性

WindowsRTC客戶端支持表3.1列出的音頻編解碼器(codec)，同時列出了相關(guān)的采樣率和比特率。選擇哪一種編解碼器取決于通信雙方的能力和帶寬。例如，如果其中一方使用56KBps的撥號連接，那么G.711將被禁用，因為它超出了可獲得的帶寬限制。又比如，假設(shè)其中一方支持SIREN，而另一方不支持，那么首選的編解碼器SIREN將被禁用。如果雙方均支SIREN并且?guī)捵銐?，那么在所有的編解碼器中SIREN即為首選。表2.1WindowsRTC客戶端支持的音頻編解碼器

Codec采樣率比特率RTP包長度

G.711Kilohertz(kHz)64kilobitspersecond(Kbps)20milliseconds(msec)

G.722.116Khz24Kbps20msec

G.7238Khz6.4Kbps30msec,60msecor90msec

GSM8Khz13Kbps20msec

DVI48Khz32Kbps20msec

SIREN16Khz16Kbps20msecor40msecH.263是視頻所支持的編解碼器，其比特率在6KBps到125KBps之間不等。出于兼容性的考慮，H.261也是被支持的編解碼器。該版本只支持OCIF（176×144）。不支持第三方編解碼器的插件。

2、回波抵消（AEC）

AEC的工作原理是通過對講話者的輸出建模，并且將其從麥克風(fēng)捕捉的信號里除去。AEC有助于確保對端聽不到回聲。

為了啟用AEC，在WindowsMessager中運行”音頻和視頻調(diào)節(jié)”向?qū)ВˋudioandVideoTuning：進(jìn)入菜單：Tools/AudioTuningWizard…）。在音頻調(diào)節(jié)部分，去掉”Iamusingheadphones”復(fù)選框前面的”√”。

使用IRTCClient接口PreferredAEC方法可以通過編程實現(xiàn)對AEC的啟用和禁用。

RTC客戶端使用的AEC模塊是MicrosoftDirectSound底層結(jié)構(gòu)的一部分。該組件包括下列特性和限制：

（1）AEC只在不超過25×15×9英尺的小房間才會有效；

（2）AEC只對單聲道有效，當(dāng)輸出是多個通道的立體聲的時候，只有一個通道能夠具有回波抵消的效果；

（3）AEC不能抵消來自其它聲音源的聲音，比如背景中收音機(jī)放出來的歌曲；

下面兩條限制只應(yīng)用于WindowsXP的RTMRTC客戶端?？蓮腤indowsUpdate下載一個包來去掉這兩條限制。

（1）AEC要求音頻捕捉和再現(xiàn)設(shè)備使用同一個時鐘，這意味著，AEC對USB音頻設(shè)備無效。如果RTC的客戶端檢測到了這樣的情況，音頻調(diào)節(jié)向?qū)е械哪莻€復(fù)選框會被禁用，以阻止用戶啟用AEC。

（2）AEC僅對采樣率為8KHZ和16KHZ的信號有用。這意味著AEC對采樣率為其它值的聲卡無效，例如基于AC97的聲卡，這種聲卡的采樣率在44KHZ左右。調(diào)節(jié)向?qū)z測到這樣的聲卡時，同樣也會禁用AEC。

可在程序里通過IRTCClient接口的PreferredAEC方法對AEC進(jìn)行控制。

3、冗余音頻編碼

冗余音頻編碼是一種補償丟包的技術(shù)。RTC客戶端實現(xiàn)了一種one-packet冗余算法。當(dāng)該算法被啟用的時候，每一個包都包含了當(dāng)前的音頻幀和前一個音頻幀。若某一個包丟失，接受者還有第二個機(jī)會在緊隨其后的包里得到該音頻幀。這個過程在IETFRFC2198中有文檔說明?？杀换謴?fù)的包的最大數(shù)目是3個。該算法根據(jù)實時通信控制協(xié)議（RTCP）所提供的信息進(jìn)行自適應(yīng)調(diào)節(jié)。

該算法開始的冗余為0，隨著丟包的發(fā)生引入冗余。原始數(shù)據(jù)包和攜帶原始數(shù)據(jù)備份的包的距離決定有多少個已丟失的包能被恢復(fù)。這一距離在1到3之間不等。例如，假如距離為2，而丟失了第n個包，那么在第n+2個包中可以獲得同樣的信息。如果丟失了第n和第n+1個包，我仍然可以在第n+2和n+3個包中獲得全部所有信息。如果我丟失了第n個、第n+1個和第n+2個包，那么第n個包的信息將無法重新獲得（因為這些信息在第n+2個包當(dāng)中）。表2.2說明在丟包率不同的情況下距離的取值。

表2.2丟包率與距離的關(guān)系

距離丟包率（低）丟包率（高）

005

1410

2915

314204、動態(tài)抖動緩沖和調(diào)整

抖動緩沖被用于通過緩沖音頻包及調(diào)整其呈現(xiàn)，從而在接收的音頻中進(jìn)行平滑延遲變化處理。這樣可以使語音更平滑地傳輸給用戶?？蛻舳丝捎幸粋€能增大到500毫秒的抖動緩沖。換句話說，這個緩沖區(qū)可以吸收接收包中500毫秒的延遲變化，而不會引起語音的抖動。

再現(xiàn)緩沖是一個兩秒的循環(huán)緩沖。如果在一個很短的時間里我們得到了超過兩秒的語音數(shù)據(jù)包，那么新收到的包將會被丟掉。

在這一版本中，抖動緩沖在新的音頻數(shù)據(jù)高峰進(jìn)行重新調(diào)整。為確保高質(zhì)量語音，發(fā)送者應(yīng)該為所有的編解碼使用靜音抑制。RTC的客戶端默認(rèn)使用靜音抑制。

5、自動增益控制（AGC）

AGC是一種根據(jù)輸入信號水平動態(tài)調(diào)整增益的機(jī)制。RTC客戶端根據(jù)所捕捉到的音量調(diào)整麥克風(fēng)的增益，以實現(xiàn)AGC。

當(dāng)音量（無論是捕捉到的音量還是再現(xiàn)的音量）超過某一門限值，信號就會被限幅。限幅指的是音頻設(shè)備的輸出不再隨著輸入而變化，輸出實質(zhì)上變成了最大音量位置上的一條水平線，這會引起聲音的中斷。當(dāng)RTC客戶端檢測到音頻增益達(dá)到了某一門限–每一個包的連續(xù)平均峰值的脈沖編碼調(diào)制的值都超過了最大門限值–它會自動減小增益來避免限幅的發(fā)生。

另一方面，如果捕捉到的音量太低（每一個包的連續(xù)平均峰值的脈沖編碼調(diào)制的值低于最低門限值），RTC的客戶端會提高增益。當(dāng)然，增益的調(diào)整不會使音量超過用戶在調(diào)節(jié)向?qū)е性O(shè)置的值。注意當(dāng)啟用AEC時增益不會被增大，因為這樣會使得AEC重新聚合，而這需要幾秒的時間。

6、帶寬估計

實際可用帶寬可能少于WindowsSocket所報告的本地連接速度。有很多因素會引起這種現(xiàn)象，包括通道的低速連接，其它應(yīng)用程序消耗的帶寬等等。

為了估計實際可用帶寬，RTC客戶端發(fā)送連續(xù)不斷的RTCP包。另一端根據(jù)包與包的延遲來估計帶寬。最初每一個RTCP包的報告都用于估計帶寬，然后逐漸減小到每三個包中的一個用于估計帶寬。

當(dāng)前，帶寬估計的結(jié)果可用于指示連接是否是LAN，并且被用作計算實際可用帶寬的上限。以后，這一算法將擴(kuò)展到能給出更多具體的結(jié)果。

7、質(zhì)量管理算法

RTC媒體的質(zhì)量管理的目標(biāo)是在不同的網(wǎng)絡(luò)環(huán)境中，通過RTC客戶端為用戶提供更好的音頻視頻服務(wù)。QC持續(xù)監(jiān)控網(wǎng)絡(luò)環(huán)境，計算輸出流的可用帶寬，動態(tài)改變音視頻輸出流的設(shè)置，以提供更平滑的流輸出、最小的抖動和延遲。在音視頻輸出流之間，QC為音頻提供更高的優(yōu)先級。

QC收到來自以下三個源之一的命令或者事件的時候，對輸出流進(jìn)行調(diào)整：應(yīng)用程序、遠(yuǎn)端和實時通信傳輸協(xié)議（RTP）模塊。應(yīng)用程序通過增加去除流或者改變最大比特率的設(shè)置來觸發(fā)對輸出流的調(diào)整。遠(yuǎn)端通過發(fā)送新的SDP（會話描述協(xié)議）來觸發(fā)調(diào)整，這反過來也會引起流和比特率的設(shè)置。RTP模塊周期性地發(fā)送RTC媒體事件來報告對端的估計帶寬和丟包率。通過接收這些事件，QC對音頻和視頻流進(jìn)行調(diào)整。

2.4IP組播技術(shù)

80年代開始，Stanford大學(xué)實施了第一項多目通話，1992年IETF定義和發(fā)布了一個多播的網(wǎng)絡(luò)標(biāo)準(zhǔn)，用于建立多播主干網(wǎng)，即在Internet上運行的單路廣播和多播綜合網(wǎng)絡(luò)，并且很快便名聲遠(yuǎn)揚。1995年，Cisco公司和Lucent公司開始銷售支持多播的路由器和交換機(jī)，一年后依賴多播的應(yīng)用產(chǎn)品開始上市。

隨著Internet/Intranet/Extranet的發(fā)展，各種多媒體通信業(yè)務(wù)也得到了廣泛

的應(yīng)用，特別是網(wǎng)絡(luò)音頻和視頻應(yīng)用正是當(dāng)前研究、開發(fā)和實現(xiàn)的熱點，大多應(yīng)用都是基于多播技術(shù)的[9]。例如:美國波士頓銀行采用多播技術(shù)在以太網(wǎng)上向250個貿(mào)易商行和其他部門分發(fā)市場數(shù)據(jù)。

對于IPv4有三種基本地址：單址廣播(unicast，簡稱為單播)，廣播(broadcast)

和多址廣播(multicast，簡稱為多播或者組播)。一個單址廣播地址是將一個包傳輸給唯一的一個目的地，一個廣播地址是將一個報文傳遞給整個子網(wǎng)，而一個組播地址是將一個報文傳遞給屬于某一個集合的主機(jī)，這些主機(jī)同屬于一個多播組，它們可位于不同的子網(wǎng)上。組播組(MulticastGroups)的含義為:單個主機(jī)可以自由地在任何時候加入或離開組播組，組播組沒有物理位置或數(shù)目大小的限制，一個主機(jī)可以在同一時刻屬于多于一個的組播組，也沒有要求必須給所屬的組播組發(fā)送報文。

組播不是基于面向連接(connection-oriented)的，一個組播包都是以相同的”盡力而為”(best-efort)的方式傳遞給目的組成員的，同標(biāo)準(zhǔn)的單址廣播的投遞方式。這意味著組播數(shù)據(jù)包即不被保證能夠到達(dá)每一個組成員，也不被保證包的傳遞順序不會被打亂。

IP組播采用D類地址，地址范圍為到55。

為了參加與本地網(wǎng)絡(luò)上的IP組播，主機(jī)必須使用允許收發(fā)多播數(shù)據(jù)的機(jī)制。當(dāng)跨越多個網(wǎng)段時，必須由本的組播路由器和其他組播路由器聯(lián)系傳送組成員關(guān)系信息，建立組播路由。這些就要靠因特網(wǎng)組管理協(xié)議IGMP(IntemetGroupManagementProtocol)來實現(xiàn)，IGMP來自SteveDeering的博士論文中的主機(jī)成員關(guān)系協(xié)議IGMP中。這里我們概括一下IGMP的工作原理。

IGMP的工作過程分為兩個階段。第一階段：當(dāng)主機(jī)加入一個新的組時，它發(fā)送一個IGMP報文給全主機(jī)組播地址，宣布這個成員關(guān)系成立，本地組播路由器接收到這個報文之后，向互聯(lián)網(wǎng)上的其它組播路由器傳播這個關(guān)系信息以建立必要的路由。第二階段：為適應(yīng)動態(tài)的成員關(guān)系，本地組播路由器周期性地輪詢本地網(wǎng)絡(luò)上的主機(jī)，以便確定現(xiàn)在的各個組中有哪些主機(jī)。如果經(jīng)過若干個輪詢后，某個組中始終沒有成員，組播路由器就認(rèn)為該組中不再有本網(wǎng)絡(luò)中的主機(jī)，于是停止向其他組播路由器通告該組的成員關(guān)系信息。

IP組播的機(jī)制目前流行有多種，我們概括如下：

第一種，距離向量組播路由協(xié)議(DVMRP)。DVMRP是Mbone上廣泛使用的多點路由協(xié)議，發(fā)送者和接收者之間建立一個基于發(fā)送者的組播樹，開始從發(fā)送者出來的數(shù)據(jù)包被送到各個組播路由器(稱為MCR,multicastrouter),MCR為每個源維持一個最佳路徑，當(dāng)MCR收到一個組播數(shù)據(jù)包時，若是從該源的最佳路徑來的則轉(zhuǎn)發(fā)給其它MCR，否則丟棄。

第二種，組播開放最短路徑優(yōu)先(MOSPF)。MOSPF是一種基于鏈路狀態(tài)的路由機(jī)制。通過使區(qū)域中的所有MCR都有一致的區(qū)域拓?fù)浣Y(jié)構(gòu)圖和組成員的分布表。當(dāng)MCR收到一個組播數(shù)據(jù)包后，用Dijkstra算法求出到所有接收者的最短路徑，再將數(shù)據(jù)包從最短路徑的端口轉(zhuǎn)發(fā)，與DVMRP相比，MOSPF是按需并從最短路徑轉(zhuǎn)發(fā)，因此路由性能大大提高。

第三種，基于核的數(shù)(CBT)。CBT是基于多目組來建立組播樹，令一個MCR作為樹的核心，稱為核心MCR。當(dāng)MCR所在子網(wǎng)或其下游子網(wǎng)上有主機(jī)加入多目組時，MCR與該組的核心MCR取得聯(lián)系，以核心MCR為根按最短路徑建立組播樹。

第四種，與協(xié)議無關(guān)的組播(PRTC)。PRTC機(jī)制融合了基于核和最短路徑樹狀態(tài)的特點。為了提高組播的效率，PRTC定義了兩個模式:密集模式和稀疏模式。密集模式的含義是在組所覆蓋的區(qū)域中，該組成員的子網(wǎng)數(shù)量在子網(wǎng)總數(shù)中占有很高的比例。可以采用反向確認(rèn)方式來有效建立組播樹。密集模式基本上與DVMRP相同，屬于數(shù)據(jù)驅(qū)動型協(xié)議.稀疏模式的含義是擁有組成員的子網(wǎng)數(shù)量遠(yuǎn)小于互聯(lián)網(wǎng)中網(wǎng)絡(luò)數(shù)量或組所覆蓋的網(wǎng)絡(luò)資源不足。因此此種模式需要限制不必要的數(shù)據(jù)包投遞以提高通信效率。

IP組播的優(yōu)點主要體現(xiàn)在三個方面，(1)節(jié)省帶寬：與點對點的傳輸方式不同，不需要發(fā)送者給每一個接收者都發(fā)出相同的數(shù)據(jù)，而僅是由組播路由器復(fù)制后進(jìn)行分發(fā)，這樣就減少了帶寬要求：(2)服務(wù)器負(fù)載降低，因為一些數(shù)據(jù)包的分發(fā)工作由組播路由器完成了；(3)網(wǎng)絡(luò)負(fù)載降低，原因同節(jié)省帶寬的理由。

當(dāng)然還是有不足之處的，(1)不可靠的信息包傳送，因為組播使用的是UDP。而UDP是一種不可靠的數(shù)據(jù)傳輸方式；(2)信息包的復(fù)制，這也是單播與多播的關(guān)鍵差別，路由器主動地發(fā)送組播信息包的拷貝到多個接口，則增加了多個拷貝的組播信息包到達(dá)某一種接收點的可能性；(3)網(wǎng)絡(luò)阻塞，該種情況主要出現(xiàn)在欲傳送的信息流的帶寬要求超過實際鏈路所能提供的帶寬，由于IP組播沒有內(nèi)建的阻塞避免機(jī)制從而引起的阻塞。第三章局域網(wǎng)實時通信系統(tǒng)的實現(xiàn)

3.1系統(tǒng)功能描述與模塊劃分

3.1.1系統(tǒng)功能描述

本課題是針對目前網(wǎng)絡(luò)環(huán)境實時通信的應(yīng)用要求，開發(fā)一個能支持視頻和語音通信的局域網(wǎng)實時通信系統(tǒng)。其主要的功能是：

1、允許多人的實時通訊

2、系統(tǒng)通過Winsock實現(xiàn)信息交流

3、支持視頻和語音通訊

4、接受注冊，并允許注冊用戶登錄

5、能夠進(jìn)行點對點的通訊和文件傳輸

6、能夠?qū)崿F(xiàn)廣播功能

3.1.2系統(tǒng)模塊劃分

1、注冊登陸模塊

本模塊完成新用戶的注冊信息存儲、登陸驗證和數(shù)據(jù)庫的管理功能[7]。該模塊通過ODBC對access數(shù)據(jù)庫的操作，將用戶的注冊信息寫入到access數(shù)據(jù)當(dāng)中。在用戶登陸的時候，將登陸信息與數(shù)據(jù)庫查詢比較，確認(rèn)是否是已注冊的用戶。另外，在此部分中還加入對了對聊天服務(wù)器的控制按鈕，以方便以注冊登陸為主的服務(wù)器更好的控制整個系統(tǒng)。

2、客戶端模塊

本模塊是整個系統(tǒng)的核心部分，也是用戶直接面對部分。根據(jù)其完成的功能可以劃分四個子模塊，分別是注冊子模塊、登錄子模塊、聊天子模塊和文件傳送子模塊。在這部分模塊當(dāng)中，還有一個比較重要的功能就是對視頻語音模塊和組播通信模塊的控制。

客戶端采用winsock通信模式，在程序運行后的第一個對話框，客戶可以選擇登陸或注冊，若是注冊則啟動注冊向?qū)?，分三步完成注冊工作，點擊確定后，客戶端將與指定的IP地址和端口號去連接注冊登陸模塊，成功連接后注冊登陸模塊執(zhí)行注冊操作，并返回注冊結(jié)果。客戶注冊成功后，即可用注冊時的用戶名和密碼進(jìn)行登陸，將登陸信息按注冊時的網(wǎng)絡(luò)設(shè)置發(fā)往服務(wù)器，服務(wù)器執(zhí)行登陸操作并返回注冊結(jié)果，登陸成功則連接聊天通信模塊，否則退出程序。登陸成功出現(xiàn)聊天對話框，可以從下拉組合框選擇好友，在文本框內(nèi)編輯信息發(fā)送給好友，聊天通信模塊收到信息后依照接收者用戶名進(jìn)行轉(zhuǎn)發(fā)。若客戶收到信息則閃動托盤處的圖標(biāo)，提示用戶收到信息，用戶可以點擊回答進(jìn)行回復(fù)。

當(dāng)?shù)顷懗晒螅脩粢部梢栽谶x擇好友后點擊傳送文件按鈕來進(jìn)行文件傳送。另外，用戶還可以點擊語音視頻按鈕、組播通信按鈕來分別啟動視頻語音模塊和組播通信模塊。

3、聊天服務(wù)器模塊

本模塊負(fù)責(zé)完成數(shù)據(jù)轉(zhuǎn)發(fā)以及共享數(shù)據(jù)結(jié)構(gòu)的管理。本模塊設(shè)計為無界面進(jìn)程，并采用共享數(shù)據(jù)結(jié)構(gòu)，為每個客戶端創(chuàng)建兩個線程，實現(xiàn)接收和轉(zhuǎn)發(fā)的功能。一個線程用于發(fā)送，一個線程用于接收。

4、語音視頻模塊

本模塊負(fù)責(zé)語音視頻功能的實現(xiàn)[8]。通過客戶端模塊的視頻通信按鈕可以啟動本模塊。模塊采用windows平臺下的實時通信API來實現(xiàn)語音和視頻通信，避免了視頻捕捉–數(shù)據(jù)編碼壓縮–數(shù)據(jù)傳輸–數(shù)據(jù)解碼–視頻顯示這個復(fù)雜的過程，簡化了整個程序。

5、組播通信模塊

本模塊主要實現(xiàn)的是組通信，當(dāng)用戶點擊客戶端上的”組播通信”按鈕時，將進(jìn)入通信組。進(jìn)入通信組以后，通信組中的任何一個成員發(fā)送信息時，所有的成員都可以接受到信息。這樣就可以可以形成一個討論組，以解決點對點通信的單一性。

3.2系統(tǒng)結(jié)構(gòu)圖

圖3.1本課題系統(tǒng)結(jié)構(gòu)圖

3.3模塊功能的實現(xiàn)

本課題采用的是Visualc++6.0平臺進(jìn)行軟件設(shè)計。本節(jié)將詳細(xì)介紹各模塊跟功能的實現(xiàn)過程。

3.3.1注冊登陸模塊功能的實現(xiàn)

注冊登陸模塊采用面向連接的并發(fā)式方式，模塊設(shè)計成為一個對話框程序[10]，其運行界面如圖3.2所示。調(diào)用WSAStartup初始化動態(tài)庫，socket函數(shù)創(chuàng)建套接字，bind函數(shù)綁定本地IP地址和端口，listen函數(shù)使套接字進(jìn)入偵聽，然后由于調(diào)用accept()函數(shù)將產(chǎn)生阻塞，所以不宜在主線程中調(diào)用該函數(shù)，因而在初始化網(wǎng)絡(luò)后當(dāng)用戶按下”運行注冊登錄服務(wù)器”按鈕后，利用偵聽套接字啟動注冊登錄線程RegLoad(void*s)進(jìn)入無限循環(huán)，在線程中調(diào)用accept()函數(shù)，用來接受來自客戶端的連接請求，每當(dāng)一個連接請求到來時，accept()函數(shù)將產(chǎn)生一個新的套接字，利用這個套接字產(chǎn)生一個新的線程talkToClient(void*cs)與客戶端進(jìn)行通信并讀寫數(shù)據(jù)庫，通信完畢后關(guān)閉該套接字和線程，原來的偵聽套接字繼續(xù)處于偵聽狀態(tài)。圖3.2注冊登陸模塊實驗結(jié)果圖

在對話框初始化的同時完成網(wǎng)絡(luò)初始化，即執(zhí)行Init_net()函數(shù)

接下來我們看看本模塊是怎么對數(shù)據(jù)庫進(jìn)行操作的，以及對客戶端發(fā)送過來的注冊或登陸信息的處理方式。

首先要建立應(yīng)用程序與數(shù)據(jù)庫，以及表的連接：其代碼如下：CStringCUser::GetDefaultConnect()

{

return_T(”O(jiān)DBC;DSN=wbQQuser”);

}CStringCUser::GetDefaultSQL()

{

return_T(”[表1]“);

}

緊接著提取出客戶端發(fā)送過來的信息，根據(jù)接收到數(shù)據(jù)的前幾個字符來判斷消息的類型是注冊還是登陸。如果是Reg則表示注冊，Load則表示登陸。當(dāng)發(fā)送過來的是注冊信息的時候，首先提取出用戶名，然后和表中已存在的用戶名進(jìn)行比較，如果存在的返回”exist”信息，并關(guān)閉線程。如果不存在，這進(jìn)行數(shù)據(jù)庫操作，將發(fā)送過來的注冊信息添加到數(shù)據(jù)庫當(dāng)中。

當(dāng)發(fā)送過來的是登陸信息的時候，則將用戶名和密碼信息與數(shù)據(jù)庫里面保存的信息進(jìn)行比較，相同則允許登陸。

1、注冊登陸模塊流程圖：圖3.3注冊登陸模塊流程圖

3.3.2客戶端模塊功能的實現(xiàn)

客戶端模塊比較復(fù)雜，這里將分為注冊子模塊、登陸子模塊、聊天子模塊、發(fā)送文件子模塊來介紹。

首先，為了讓客戶端和服務(wù)器能夠協(xié)同工作，必須在通信過程中定義一套規(guī)則也就是網(wǎng)絡(luò)通信協(xié)議，讓雙方能夠相互聽懂，并依照協(xié)議執(zhí)行相應(yīng)的功能塊[11]。

客戶端注冊時發(fā)送的消息為Reg:+BasicDlg.m_strUserName+BasicDlg.m_n

Age+sex+BasicDlg.m_strPassWd+MiscDlg.m_strTruName+MiscDlg.m_strCity+MiscDlg.m_strEmail+res+MiscDlg.m_strTel，注冊時發(fā)送消息的頭部為Reg。登陸時發(fā)送的消息為：Load:+m_strUserName+m_strPassWd，登陸時發(fā)送消息的頭部為Load。

登陸成功后，客戶端將自己的用戶名發(fā)送給聊天通信服務(wù)器，服務(wù)器為客戶端創(chuàng)建一個套接字，兩個線程，并填充socketInfo結(jié)構(gòu)，連入鏈表?？蛻舳税l(fā)送消息結(jié)構(gòu)為：”接收者用戶名”+“：”+“發(fā)送者頭像ID”+“~”+“（星期、月、日、年、時、分、秒）”+””+”發(fā)送者用戶名”+”->”+“接收者用戶名”+””+“發(fā)送的消息”，其頭部均為接收者用戶名，服務(wù)器依照用戶名查找鏈表，截掉頭部后把原信息進(jìn)行轉(zhuǎn)發(fā)，若客戶端關(guān)閉，則發(fā)送消息為”Close!”，服務(wù)器從鏈表中刪除相應(yīng)項。

客戶端可能收到的消息有三種，第一種為普通消息，結(jié)構(gòu)如前所述；第二種為”SendFile!”，表示對方想向己方傳送文件；第三種為”Refuse！”，表示對方拒絕接收己方文件。

1、注冊子模塊

注冊子模塊相對來說比較簡單，只需要把用戶填寫的用戶信息按上面介紹的順序發(fā)送到注冊登陸服務(wù)器去處理，其他的活動它不需要參與。所以，這里也不做過多的介紹。只是需要說明的一點的是，注冊信息中有一項是網(wǎng)絡(luò)設(shè)置。在這里需要設(shè)置登陸注冊服務(wù)器和聊天服務(wù)器的地址，當(dāng)填寫完成以后，將在本地生成一個net.cfg文件。這個文件非常重要，下次登陸時，就是根據(jù)這個文件的設(shè)置來連接服務(wù)器。注冊子模塊注冊向?qū)Ы缑嫒鐖D3.4所示，運行結(jié)果如圖3.5所示。圖3.4客戶端注冊登陸子模塊部分實驗結(jié)果圖

圖3.5客戶端注冊登陸子模塊部分實驗結(jié)果圖

2、登陸子模塊

登陸子模塊也只需要把用戶名和密碼信息按照自定義協(xié)議的格式發(fā)送給登陸注冊服務(wù)器，然后由服務(wù)器來處理。用戶名和密碼正確，則登陸成功。其客戶端界面如圖3.6所示。圖3.6客戶端登陸子模塊實驗結(jié)果圖

3、聊天子模塊

聊天子模塊是客戶端最重要的一個模塊。登陸成功以后，即進(jìn)入客戶端主界面，主界面如圖3.7所示。用戶可以在下拉菜單中選擇聊天的對象，然后文本框中編輯信息，按”發(fā)送”鍵發(fā)送。子模塊設(shè)定了一個用于接收數(shù)據(jù)的RecvThread(void*cs)線程。

圖3.7客戶端聊天子模塊實驗結(jié)果圖RecvThread函數(shù)代碼如下：UINTRecvThread(void*cs)

{

提取信息中”：”以前的信息，用于判斷消息類型；

判斷接受到消息的類型；

if消息類型為SendVido!

{

獲取發(fā)送者用戶名；

顯示提示框，是否接受對方的請求與對方進(jìn)行視頻通信；

if(同意對方請求)

{

啟動視頻通信模塊；

獲取本地IP地址；

發(fā)送本地IP地址給視頻請求者；

}

Else不同意對方的請求

{

發(fā)送拒收請求消息；

}

continue;

}

//////////////////////////////////////////////////////////////////////////////////

if消息類型為SendFile！/對方要給我發(fā)送文件

{

獲取發(fā)送者用戶名；

顯示提示框，是否接受對方的請求與對方進(jìn)行文件傳輸；

if(同意對方請求)

{

開始接收文件線程

}

Else不同意對方的請求

{

拒絕接受文件；

}

continue;

}

if消息類型為拒絕//對方拒絕接收文件

{

顯示對話框，提示對方拒絕你的請求；

}

}4、文件傳輸子模塊

傳輸文件某種程度上來說是依托于聊天子模塊的?？蛻舳薃想給客戶端B傳送文件，則發(fā)送消息為”SendFile!”，B收到”SendFile!”后彈出消息框，提示對方向己方傳送文件，接收按”是”，執(zhí)行文件接收功能；拒絕按”否”，發(fā)送”Refuse!”其運行結(jié)果如圖3.8所示。

圖3.8客戶端傳輸文件子模塊文件發(fā)送端流程圖

當(dāng)對方接受到請求信息后，執(zhí)行如下代碼：（此部分代碼時前面所介紹的RevThread()函數(shù)中的一部分）UINTRecvThread(void*cs)

{

If對方要給我發(fā)送文件

{

獲取發(fā)送者的用戶名；

顯示對話框，提示是否接受文件；

if同意接受文件

開始接收文件線程

}

else

{

發(fā)送拒收文件消息

}

}

If對方按下”拒絕”按鈕

{

顯示對話框，提示對方拒絕接受文件

關(guān)閉發(fā)送文件線程；

}

當(dāng)對方同意接受文件以后，客戶端A選擇需要發(fā)送的文件，然后開始發(fā)送文件。發(fā)送完文件名信息以后，暫停。客戶端B選擇保存文件的路徑，然后再繼續(xù)傳送文件。文件傳送完畢以后，跳出對話框，提示操作完成。運行結(jié)果如圖3.9所示。圖3.9客戶端傳輸文件子模塊實驗結(jié)果圖傳輸文件模塊設(shè)定了兩個線程，一個用于接收、一個用于發(fā)送–UINTrecvFile(void*data)、UINTsendFile(void*name)。通過這兩個線程來實現(xiàn)文件的接受和發(fā)送。

（1）傳輸文件子模塊流程圖，如圖3.10所示。圖3.10客戶端傳輸文件子模塊文件發(fā)送端流程圖（2）文件接收端程序流程圖，如圖3.11所示。

圖3.11客戶端傳輸文件子模塊文件接收端流程圖

3.3.3聊天服務(wù)器模塊功能的實現(xiàn)

聊天通信服務(wù)器設(shè)計為無界面的進(jìn)程，創(chuàng)建時先建一個基于對話框的應(yīng)用程序，然后把對話框類刪除，把APP類里面與對話框有關(guān)的語句全刪，就建立了一個無界面的進(jìn)程。本模塊是整個系統(tǒng)實現(xiàn)的關(guān)鍵，它運用共享數(shù)據(jù)結(jié)構(gòu)技術(shù)及多線程技術(shù)，通過I/O端口56790與用戶端連接，實現(xiàn)了數(shù)據(jù)轉(zhuǎn)發(fā)功能。首先，程序初始化網(wǎng)絡(luò)Init_net()，接著當(dāng)用戶連接到服務(wù)器時，創(chuàng)建接收線程和發(fā)送線程，這樣就可以實現(xiàn)數(shù)據(jù)轉(zhuǎn)發(fā)[12]。最后，當(dāng)用戶斷開連接時，服務(wù)器關(guān)閉與他的連接，并結(jié)束相應(yīng)的線程。

1、共享數(shù)據(jù)結(jié)構(gòu)

本模塊的共享數(shù)據(jù)結(jié)構(gòu)一共有兩個，即socket_info和send_info。前者包含了所有登陸用戶的一些基本資料，后者則包含了當(dāng)前服務(wù)器接收到的用戶端所發(fā)送的信息資料。詳細(xì)內(nèi)容及注釋如下：structsocket_info

{

SOCKETs_client;//用戶的SOCKET值

u_longclient_addr;//用戶網(wǎng)絡(luò)地址

CStringpet;//用戶昵稱

CWinThread*thread;//為該用戶創(chuàng)建的發(fā)送線程對象的指針

};structsend_info

{

CStringdata;//用戶端發(fā)送的數(shù)據(jù)內(nèi)容（經(jīng)過編輯）

CWinThread*thread;//需要發(fā)送數(shù)據(jù)的任務(wù)指針

};

在程序中，定義兩個全局變量，用來在線程間共享：send_infoinfo_data;CLists_info;每當(dāng)有用戶連接到服務(wù)器，服務(wù)器就將用戶端的一些信息以socket_info結(jié)構(gòu)體的形式存入s_info列表中；而當(dāng)服務(wù)器接收到用戶端發(fā)送過來的數(shù)據(jù)時，就將數(shù)據(jù)格式化后存入結(jié)構(gòu)體info_data，通過與結(jié)構(gòu)體列表比較，確定需要恢復(fù)的發(fā)送線程（所有發(fā)送線程在創(chuàng)建時都被掛起）。這樣，服務(wù)器就準(zhǔn)確地轉(zhuǎn)發(fā)了數(shù)據(jù)。

2、多線程

每當(dāng)服務(wù)器上有用戶連接成功，服務(wù)器都會為其創(chuàng)建兩個線程：接收線程（RecvData）和發(fā)送線程（SendData），并且接收線程在創(chuàng)建后處于可執(zhí)行狀態(tài)，而發(fā)送線程則阻塞，等待服務(wù)器將其喚醒。這兩個線程都執(zhí)行一個無限循環(huán)的過程，只有當(dāng)通信出現(xiàn)異?；蛴脩舳岁P(guān)閉連接時，線程才被自身所結(jié)束，并且，這兩個線程一定是同時生成，同時結(jié)束的。很顯然，每個連接產(chǎn)生兩個線程，使得數(shù)據(jù)轉(zhuǎn)發(fā)變的簡單，但同時又使得服務(wù)器的任務(wù)加重。因此，用戶端的連接數(shù)量有所限制，視服務(wù)器軟、硬件能力而定。

同時，由于多線程對結(jié)構(gòu)體info_data都需要操作，所以線程間必須同步。這里，定義了互斥量CMutexm_mutex，用它的方法Lock()和Unlock()來完成同步。3、聊天模塊流程圖，如圖3.12所示

圖3.12聊天通信模塊流程圖

3.3.4語音視頻模塊功能的實現(xiàn)

1、實時通信客戶端接口

需要的頭文件：rtccore.h

增強(qiáng)功能的應(yīng)用程序獲得帶有使用CLSID_RTCClient的CoCreateInstance()的實時通信客戶端接口。一旦這個接口可用，Initialize()這個COM對象來判斷這個平臺的通信會話性能。//初始化RTCCOM對象

hr=CoCreateInstance(CLSID_RTCClient,NULL,

CLSCTX_INPROC_SERVER,IID_IRTCClient,

(LPVOID*)&m_pClient);

//初始化客戶端接口

hr=m_pClient->Initialize();

2、選擇通信類型

下一步是選擇偏愛的通信和相關(guān)設(shè)備（攝像頭和麥克風(fēng)）的類型。缺省設(shè)置情況是能使用所有的通信類型。如果通信會話的參與者能夠共享應(yīng)用程序、傳遞實時消息、聲音的和視頻，這些性能都能夠自動的可用。如果一個參與者不支持某種特定的通信類型，那么對于所有的會話參與者來說，這種通信類型也是不可用的。m_pClient->SetPreferredMediaTypes(RTCMT_ALL,VARIANT_TRUE);視頻：Windows實時通信客戶端在1/4CIF圖象格式（176×144）分辨率下支持H.261和H.263編解碼器。這些可變比特率編解碼器發(fā)送界于6-125Kbps的視頻數(shù)據(jù)。使用IRTCClient接口方法put_MaxBitRate和put_TemporalSpatialTradeOff可能影響目標(biāo)的視頻轉(zhuǎn)換的空間時間分辨率。

音頻：Windows實時通信客戶端支持許多種音頻編解碼器。音頻編解碼器是基于終端的連接質(zhì)量而定的。

3、初始化一個會話

在應(yīng)用程序能夠與其它參與者連接之前，它必須能夠處理在會話期間實時通信fireoff的事件。在PC到PC的通信中，應(yīng)用程序捕獲實時消息、音量強(qiáng)度、媒體、客戶端消息和會話狀態(tài)改變等事件。下面的代碼說明了如何只創(chuàng)建一個事件過濾器來捕獲特定的RTC事件類型。

lEventMask設(shè)置了應(yīng)用程序感興趣的一組事件。（如果想要得到一個完整的事件列表，請在MSDN網(wǎng)站上搜索RTC_EVENT以便取得每個事件的詳細(xì)信息）。

CRTCEvents類為附屬的客戶端發(fā)送事件。RTCEvents對象在應(yīng)用程序和RTCEventNotification接口之間創(chuàng)建一個接口。所有的實時通信事件將由RTCEvents類處理。

在一個會話期間，音頻與視頻媒體類型可以被添加也可以被刪除，所以客戶端必須監(jiān)聽這些事件類型。

4、處理實時通信事件

一旦事件處理器被RTCEventNotification接收端注冊，那么接收和處理實時通信事件就非常簡單了。當(dāng)實時通信事件被樣例應(yīng)用程序接收的時候，應(yīng)用程序的事件處理程序發(fā)送一個消息到這個應(yīng)用程序的消息處理程序。OnRTCEvent()函數(shù)處理所有的由應(yīng)用程序接收的所有的不同類型的事件。

5、創(chuàng)建一個通信會話

在能夠使用實時通信之前，必須創(chuàng)建和初始化一個通信會話。然后你就可以輸入?yún)⑴c者的IP地址來開始通話了。也可以通過輸入一個電子郵件地址或者一個電話號碼來激活一個通信會話。然而，這個函數(shù)需要SIP注冊服務(wù)器，這在本文討論范圍之外了。我們將在下篇文章中談?wù)勥@個話題。

實時通信不支持多個視頻會議會話同時運行，所以這個應(yīng)用程序在初始化一個新的會話之前，必須首先檢驗?zāi)壳皼]有運行視頻會議會話。在第一個發(fā)行版本中，Windows實時通信客戶端只支持多個電話到電話的通信會話，而不支持多個音頻與視頻或者只有音頻的會議。

為了與另一臺計算機(jī)通話，需要識別實時通信會話類型并創(chuàng)建一個使用IRTCSession接口的會話類型。下面的代碼說明如何創(chuàng)建會話。

6、結(jié)束會話

為了結(jié)束一個通信會話，所有運行的應(yīng)用程序必