局域网语音视频实时通信软件开发

('随着计算机网络技术的高速发展，多媒体信息通信已经上升到了一个更高的程度-实时性。由此产生了一个新的名词，实时通信。相对于传统的电话、E-mail等通信方式来说，实时通信不仅节省费用，而且效率更高。论文给出了能够支持登陆注册、点对点文件传输、视频语音通信、多用户聊天等功能的局域网实时通信系统的设计与实现。在实时通信中，特别是多媒体的实时传输中，对传输时延有非常高的要求。针对这一特点，整个系统采用UDP作为传输层协议，因而在很大程度上减少了因重传造成的时延，同时也减轻了由此造成的网络带宽损耗。其次，设计并采用多线程和共享数据库技术，实现了多用户聊天的功能，使相互之间能够独立的通信。最后，在语音和视频通信的功能的实现上，采用了windows系统提供的windowsRTC（real-timecommunication，实时通信）API。WindowsRTCAPI为任何基于MicrosoftWindowsXP的应用程序提供了卓越的基于个人计算机的通信性能–即时消息、音频与视频会议、应用程序的共享/协作。采取这样的方法，简化了实现过程，也丰富了程序的功能。本课题以windows作为开发环境，采用C++开发工具，在相关网络编程设计实例的基础上，建立了能支持语音和视频通信等功能的实时通信系统。关键词：实时通信多线程文件传输语音/视频Winsock摘要IABSTRACTIII第一章绪论11.1本课题研究的目的和意义11.2实时通信的发展及现状21.2.1实时通信发展历史21.2.2实时通信发展趋势以及发展过程中需解决的问题4第二章WINSOCK通信实现概述62.1WINSOCK通信原理62.1.1TCP和UDP62.1.2客户机/服务器模式72.1.3WINSOCKAPI主要函数简介82.1.4WINSOCK程序通信过程92.2多线程编程102.2.1线程和进程102.2.2线程通信与同步112.3WINDOWS实时通信API122.4IP组播技术15第三章局域网实时通信系统的实现183.1系统功能描述与模块划分183.1.1系统功能描述183.1.2系统模块划分183.2系统结构图193.3模块功能的实现203.3.1注册登陆模块功能的实现203.3.2客户端模块功能的实现223.3.3聊天服务器模块功能的实现283.3.4语音视频模块功能的实现303.3.5组播通信模块功能的实现32第四章总结与展望354.1实践结果分析354.2展望35致谢37参考文献37附录37摘要ABSTRACTWiththecomputernetworktechnologyhighspeeddevelops，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-transmissionvoice/videoWinsock第一章绪论1.1本课题研究的目的和意义近十多年来电信业和互联网的突飞猛进显然是一场行进中的革命，它们合力推动着人类社会进入信息和体验经济时代。这场革命不仅正空前地革新着人们的通讯和沟通方式，大大提高社会生产与企业运作效率，而且给整个社会的诸多方面带来深层次的影响和冲击，导致了社会文化和价值观的嬗变，引发了产业变革，促进了新兴行业的诞生，并带动了相关产业的迅速成长。实时通信（RTC，real-timecommunication）即是这场革命的产物之一。它是一种使人们能在网上识别在线用户并与他们实时交换消息的技术[1]。实时通信源自ICQ。四位以色列籍年轻人在1996年7月成立了Mirabilis公司，并于同年11月推出了全世界第一个实时通信软件ICQ（目前ICQ已经归AOL旗下所有），意为”我在找你”–”ISeekYou”，简称ICQ。典型的实时通讯是这样工作的当好友列表中的某人在任何时候登录上线并试图通过你的计算机联系你时，实时通讯系统会发一个消息提醒你，然后你能与他建立一个聊天会话并键入消息文字进行交流。实时通讯被认为比电子邮件和聊天室更具有自发性，甚至你能在进行实时文本对话的同时一起进行语音视频聊天。RTC曾经只是众多非常不起眼的互联网应用中的一个，因其赢利前景被认为遥不可及，所以当初极少有人看好RTC的发展。但是，经过短短数年，RTC却迅速成长为最核心的一项互联网应用，一些RTC运营商也开始源源不断地获得巨大经济收益，腾讯QQ成功的”神话”即是其中最典型的案例，更令业界大跌眼镜的是，长大后的QQ不仅真正成了一部挣钱机器，而且似乎拥有一种神奇的魔力，无论它是出击门户、还是杀入网游，均在极短时间内便取得巨大突破和成功，并令领域内原来领先者们的地位岌岌可危。腾讯QQ的四处出击、所向披靡给中国的互联网业界造成了一场不小的恐慌，而恐龙级的电信运营商似乎同样隐约感觉到了QQ们暗藏的某种杀机，也纷纷有些坐立不安了。于是，我们见到了如下景象：各大门户网站纷纷大举进军RTC领域，电信运营商也已经或正在谋划推出自己的RTC服务，同时也还有许许多多来自四面八方的掘金者也满怀希望地进入到这块领地。一时间，实时通信成了最热闹非凡的地带，RTC也成了通信及互联网行业最热门的名词之一。1.2实时通信的发展及现状1.2.1实时通信发展历史从1996年第一个商业化的RTC产品ICQ发明到2005年，RTC行业的发展可以分成三个时期[1]，即技术培育期（1996年-2000年）、产品应用期（2001年-2004年）和产品创新期（2004年以后）。1、技术培育期的RTC（1996年-2000年）从1996年到2000年，以ICQ的出现为标志，世界各地对RTC产品的研究和开发主要停留在技术培育期阶段，在美国，AOL（美国在线）1998年6月收购了ICQ，同时自己开发了ARTC（AOLInstantMessenger）。IT业的巨头微软公司则于1999年7月发布了自己的RTC产品：MSNMessenger。而Yahoo则于1999年6月推出自己的RTC产品：YahooMessenger。在中国，深圳腾讯公司1999年2月推出了RTC产品QQ，至此RTC行业的竞争格局基本形成。本阶段的RTC产品处在一个突破技术瓶颈，保持RTC通讯的稳定性为主的阶段。此阶段世界各国的网络接入都处在拨号上网向宽带过渡的阶段，RTC用户经常断线，通讯质量不稳定，很多时候RTC服务器必须承担中转实时消息的任务，同时用户数的爆炸性增长对于RTC系统的性能和效率提出了很大的挑战。2、产品应用期的RTC（2001年-2004年）2000年之后，RTC厂商的用户圈地运动逐渐完成，各个厂商都在寻找RTC产品的赢利模式，他们发现仅仅依靠简单的文字实时交流和在线感知功能几乎不可能向用户收费，事实上任何一家厂商如果对用户注册使用其RTC产品收费的话，用户马上就会流失到提供免费服务的竞争对手那里去，ARTC、YahooMessenger、QQ、MSN、ICQ是几家主要的厂商，事实上各个国家还有大大小小数十家小厂商，竞争非常激烈。为了打破这个困境，在美国MSNMessenger采取了绑定微软自身的门户网站（www.msn.com）的模式来赢利，用户在MSNMessenger中就可以点击新闻链接从而自动启动系统默认浏览器到MSN门户网站进行浏览，还可在MSNMessenger中输入关键字提交到默认的搜索引擎站点后启动浏览器显示搜索结果，同时为提高用户对MSNMessenger的黏性，微软在MSNMessenger中加入了其他更丰富的应用：点对点的文件传输、视频/音频对话、与移动电话集成等，所有这些应用都超出了2000年之前RTC产品的标准模式，使得RTC向多媒体、内容服务和移动应用方面发展。同样，YahooMessenger、QQ、ICQ和ARTC都在发展各自的客户应用，从大方向来看，都和MSNMessenger一样往多媒体、内容服务和移动应用方面发展，但由于每家运营商的背景不同，导致各自的应用重点不同，例如QQ在手机短信、移动设备方面的优势在全球范围内都比较独特，导致其赢利主要来自于手机短信收费。而ARTC和ICQ由于其运营商AOL是美国最大的互联网接入服务商（ISP：InternetServiceProvider），因此其收入并不直接来自RTC产品本身，而是通过用户使用RTC产品时带来的互联网接入服务收入来赢利，YahooMessenger的赢利模式和功能特点与MSNMessenger很类似，甚至其用户群体有相当的重合，Yahoo主要是想通过YahooMessenger来提高其门户网站的访问量，而Yahoo作为美国第一大门户站点，其赢利模式已经比较成熟，即收入主要来源于广告。这个时期由于产品应用开始成型，导致每个产品的业务模式逐渐固定下来，各个产品的用户定位也开始逐渐清晰，如QQ在中国主要定位在30岁以下的年轻人，代表着一种时尚，而MSNMessenger在中国主要定位于办公室中的商务人士，这直接导致了两者的应用有很大的差别。总的来说，这段时间的RTC应用摆脱了早期单调的文本实时通讯，开始针对不同的用户群体开发了丰富多彩的应用，使RTC用户数仍然保持很高的增长速度。3、产品创新期的RTC（2004年以后）2004年之后，各个厂商对RTC用户的争夺更加激烈，同时互联网上的新应用发展速度更加快，很多功能非常具有创新性，并且这种创新性的应用传播速度非常之快，远远超出了传统工业中新技术的扩散速度。这些应用当中比较具有代表性的有博客（WebBlogger：也称为网络日志）、RSS（ReallySRTCpleSydicattion）、音乐文件共享、视频点播（VOD：VideoOnDemand）等，为了保持用户对RTC软件的黏性，各个厂家都想尽办法将这些新技术部署到新版本的RTC产品中去。同时，由于用户增长速度已经开始下降，社会上要求现有RTC运营商之间实现互联互通的呼声越来越高，在产品应用期阶段中开始讨论的标准统一问题的解决进度大大加快，互联网上主要的标准制订组织IETF（InternetEngineeringTaskForce）对RTC行业技术标准的讨论进入了实质性阶段。部分厂商之间的RTC产品已经开始了互通的尝试，这使得原来依靠封闭协议来保持用户忠诚度的RTC厂商开始转变策略，目前已经肯定不同RTC产品之间的互联互通是未来的发展方向，但具体到每个厂商，其进度和实施策略却由于商业利益而有很大的差异，互通性本身实际上已经成为RTC产品的一个创新性。本阶段的另一个重点创新是RTC技术开始进入企业内部网（Intranet），或者称为企业级RTC，如腾讯公司的RTX、微软公司的LCS、AOL的EnterpriseARTC等，这直接导致了RTC的应用向企业级软件层次发展。另一个重要的发展是人们对RTC产品的安全性开始重视起来，特别是2004年几次大的计算机病毒流行都是通过QQ、MSNMessenger等RTC产品传播，使不少企业禁止在内部网络中使用RTC软件，但这也导致RTC安全管理软件市场开始兴起，国外不少公司开始专门开发产品管理企业内部的RTC应用。1.2.2实时通信发展趋势以及发展过程中需解决的问题由于实时通信软件的兴起，能够进行实时互通的”内容”正迅速由语音全面扩展到图像、文字、数据等方面，它给我们的生活带来了翻天覆地的变化。不过”多功能”还不是实时通信的全部内涵，能够跨越互联网、手机、固定电话等多个平台进行通信才是实时通信未来的价值所在。一位业内人士认为，实时通信已经跨越原来狭义上的”网络”概念，正向更为广义的方向发展，未来的实时通信软件可以让我们随时随地和任何人进行任何方式的沟通，不仅是语音，还包括图像、资料、数据等等，不仅在电脑上，还可以在手机、固定电话等任何终端上。但是，我们应该看到，同其他的互联网应用一样，实时通信原本是电脑玩家的宠物，一旦上升到商务层面，其发展面临的问题便日渐突出，其中安全和互联互通便是当前实时通信发展的软肋。这也是未来实时通信软件进一步发展的趋势。实际上，实时通信软件之间要实现互联互通将主要涉及到技术和利益两个方面：在技术上，实时通信软件之间互联互通的技术操作难度并不高，软件之间实现兼容、实现互联互通完全可以做到。去年9月，美国路透社、AOL就签署了一项合作协议以实现两家公司的实时通信服务软件之间的互相开放。这样，路透社实时通信软件的用户将能够”看到”登录到包括ARTC、ICQ在内的AOL公司实时通信服务系统上的用户，并与他们互相通信。目前互联互通难，就难在互联互通企业间的利益分配上。因为多数实时通信软件的用户，都希望通过实时通信软件寻找网友实现网络交流，当然会首先选择使用已经拥有相当多使用者的实时通信软件。一般来说，用户群体庞大的实时通信软件在功能上必定已相当完善，在程序运行上会更加稳定，这也是许多用户青睐QQ、MSN的主要原因。由此，”强者愈强，弱者愈弱”。而对于腾讯QQ、MSN这样已经拥有数百万用户的企业而言，他们更愿意将精力放在对自身实时通信产品的进一步研发上，产品间的互联互通在一定程度上会分流这些企业的潜在用户甚至现有用户。如果能够解决利益分配上的问题，互联互通实现的就将在不远的将来。实时通信未来的发展还有一个很重要的的就是：安全方面，无论是个人用户，还是企业用户，都面临新的威胁。对于个人用户来说，通过实时通信软件传播的病毒就像潜藏的炸弹，一旦爆发，轻则资料丢失，重则电脑瘫痪，更有甚者，会造成实时通信用户之间的误会。而对于企业级用户来说，一个重要问题就是大多数实时通信系统是公开的，这意味着用户只要知道另一个用户的实时通信地址，他就可以直接向对方发送信息，这对于员工向外界泄露企业的商业秘密非常便利。而且实时通信的主要特点是两台终端之间可以直接进行交流，而不必通过任何第三方服务器中转。这就使得网络监管对实时通信用户的数据交换进行监控的难度增加，这让企业管理者大为头疼。实时通信的广泛使用以及它本身缺乏安全功能的特性，为向它添加加密、归档和日志功能的产品创造出了很大需求。不过，只要拥有庞大的用户群，并且能够有现实的商业利益，上述的两个难题都会得到解决。最近，AOL、微软和雅虎正相互合作让各自的实时信息服务实现企业环境内的互通，这也是这些业界领袖为了让三种不同系统的电脑用户相互通信的首次重大合作和突破。三巨头将公布为打破各自网络间的”电子围墙”，让实时通信在商务领域获得更大范围应用的合作计划。为了使用这种新系统，企业要先行获得微软网络软件的授权，这种软件将会充当连接AOL、微软、MSN和雅虎各自运作的系统的网络中心。在安全方面，企业应用的要求显然更高。实时通信软件为适应用户的需求，不断提高系统的通信能力，即通过防火墙的能力，这就为安全带来负面作用。这就要求企业必须综合考虑防火墙、防病毒、入侵监测、安全评估、VPN等多种产品，根据网络的具体拓扑和应用的具体需求，制订整体的解决方案和安全策略。专家建议，企业可以建置企业内部封闭式的实时信息系统。所谓封闭式实时信息系统是在企业内部建立自己的实时信息服务器，在每台个人计算机上安装特定的实时信息程序，这个程序可以是企业自己开发的，也可以是通用的，比如BQQ、MSN等。实时信息系统完全运作在企业的Intranet环境并不与外界有任何联系。其优点是可以为企业提供更为安全、可靠的音视频文件及信息传输服务，同时网络管理人员还可对企业内部实时信息进行更加有效的管理。此外，在企业内部设置实时信息网关也是一种有效的途径，每一个员工都可以使用通用的实时信息程序进行方便、快捷的实时通信，但必须通过公司内部的实时信息网关，通过实时信息网关对信息进行过滤和管理，任何进出的实时通信信息都必须留下记录(日志文件)，必要时信息管理人员可以根据这些记录追查来龙去脉。第二章Winsock通信实现概述2.1Winsock通信原理2.1.1TCP和UDP1、TCP报文段格式两台机器之间的TCP传输的数据单元叫报文段（segment）。TCP通过报文段的交互来建立连接、传输数据、发出确认、通告窗口大小以及关闭连接[2]。TCP每个报文段分为两个部分：首部和数据。首部携带了所需的表示和控制信息源。端口（SOURCEPORT）和目的端口（DESTINATIONPORT）字段包含了连接两端对应应用程序进行标识的TCP协议端口号。序号（SEQUENCENUMBER）字段指出了这个报文段在发送方的数据字节流的位置。确认号（ACKNOWLEDGEMENTNUMBER）字段指出了本机希望接受的下一个八位组的序号。2、UDP协议的报文格式在TCP/IP协议族中，用户数据报协议UDP（UserDatagramProtocol）是传输层上另一个重要的协议[3]。它为应用程序之间提供面向无连接的不可靠的数据报的传输服务。UDP使用底层的Internet协议，在各机器之间传输报文，提供和IP一样的不可靠的、无连接数据报交付服务。它是一个非常简单的协议没有使用确认机制来确保报文到达，没有对传入的报文重新排序的功能，也不提供反馈信息来控制机器之间信息流动的速度。所以UDP的报文传输可能出线丢失、重复、延迟以及乱序的错误。源端口（SOURCEPORT）字段和目的端口（DESTINATIONPORT）字段包含了16比特的UDP协议端口号，以便在各个等待接收报文的进程之间对数据报进行多路分解操作，其中源端口字段是可选的。3、TCP和UDP的区别在TCP/IP模型中，传输层介于网络层和应用层之间是一个需要在主机间实现高可靠性的数据包交换的网络层面。为了在并不可靠的网络上实现面向连接的可靠的传送，数据传输层必须解决数据传输的可靠性、流量控制以及连接问题。因此传输层协议必须是一种面向连接的端到端的可靠协议。在TCP/IP模型中支持传输层的网络协议主要有两种：TCP协议和UDP协议。这两种协议由于传输机制上的不同，向上层提供的网络服务也就不同。对于应用程序来说，必须根据应用程序特定的服务质量来选择不同的传输层协议。TCP提供了一个完全可靠的面向连接的传输服务。为了在服务器端和客户端之间传送TCP数据，必须首先建立一个虚拟电路，也就是建立一个TCP连接。TCP链接的可靠性，它是在牺牲了链接速度而确保了连接的可靠性。由于TCP连接是可靠的，因而也保证了传送数据包的顺序。另外在传送数据的过程中，TCP采用了超时重传机制，对时延增加的响应就是重传数据报，从而把数据丢失率控制在一个相对小的范围内。但是TCP丰富的功能有时会导致不可预料的性能低下，当网络状况不好时这种重传机制可能造成大量数据需要重新传送，从而很容易造成网络拥塞现象的出现。与TCP不同，UDP向应用层提供的是无连接的传输服务。这种服务不需要通过三次握手来确保链路的可靠性。由于链路的不可靠性使得数据传输变得不可靠，也不能够保证数据报按顺序地递交。但是UDP的重要特点是协议的开销小，因此，在很多场合中还是相当实用的。通过对TCP和UDP介绍和比较，针对本文所涉及的多媒体数据实时通信系统而已，首先需要选择哪种传输层协议作为多媒体实时通信的传输方式。很明显，在需要强调完整性和可控性时，TCP无疑是当然的选择。但在本文所关心的多媒体实时数据时，UDP则是最好的选择其优越性体现在如下几点[4]：(1)多媒体通信中，系统对数据包的丢失率具有一定的容忍度，对传输时延却有很高的要求，系统不希望因为重传数据包而增加网络的传输时延。(2)多媒体通信中，支持多媒体通信的一些实时传输协议，如RTP协议，本身已经能够处理流控制和顺序化。所以，不需要传输协议进行同样的工作，否则，将会降低系统的效率。(3)多媒体通信中，经常用到组播Multicast机制，需要使用UDP这样的无连接的传输层协议。因为UDP能够在实时环境中提供任意方式的通信，它不但能让一对应用之间进行通信，还可以让单个源向多个接收端进行组播，甚至能允许任意一组应用向任意一组接收方发送数据。用数学术语来说，UDP支持一对一、多对一、一对多以及多对多的通信方式，而面向连接的传输层协议不适用于这些功能。综上所述，针对多媒体实时数据采用UDP作为传输层协议很大程度上减少了因重传造成的时延，同时也减轻了由此造成的网络带宽损耗，从而提高整个系统的执行效率。2.1.2客户机/服务器模式在TCP/IP网络中两个进程间的相互作用的主机模式是客户机/服务器模式(Client/Servermodel)。该模式的建立基于以下两点[5]：1、非对等作用；2、通信完全是异步的。客户机/服务器模式在操作过程中采取的是主动请示方式：首先服务器方要先启动，并根据请示提供相应服务：（过程如下）（1）打开一通信通道并告知本地主机，它愿意在某一个公认地址上接收客户请求。（2）等待客户请求到达该端口。（3）接收到重复服务请求，处理该请求并发送应答信号。（4）返回第二步，等待另一客户请求（5）关闭服务器。客户方：（1）打开一通信通道，并连接到服务器所在主机的特定端口。（2）向服务器发送服务请求报文，等待并接收应答；继续提出请求……（3）请求结束后关闭通信通道并终止。2.1.3WinsockAPI主要函数简介1、创建套接字–socket()功能：使用前创建一个新的套接字格式：SOCKETPASCALFARsocket(intaf,inttype,intprocotol);参数：af:通信发生的区域type:要建立的套接字类型procotol:使用的特定协议2、指定本地地址–bind()功能：将套接字地址与所创建的套接字号联系起来。格式：intPASCALFARbind(SOCKETs,conststructsockaddrFARname,intnamelen);参数：s:是由socket()调用返回的并且未作连接的套接字描述符（套接字号）。其它：没有错误，bind()返回0，否则SOCKET_ERROR地址结构说明：structsockaddr_in{shortsin_family;//AF_INETu_shortsin_port;//16位端口号，网络字节顺序structin_addrsin_addr;//32位IP地址，网络字节顺序charsin_zero[8];//保留}3、建立套接字连接–connect()和accept()功能：共同完成连接工作格式：intPASCALFARconnect(SOCKETs,conststructsockaddrFARname,intnamelen);SOCKETPASCALFARaccept(SOCKETs,structsockaddrFARname,intFARaddrlen);4、监听连接–listen()功能：用于面向连接服务器，表明它愿意接收连接。格式：intPASCALFARlisten(SOCKETs,intbacklog);5、数据传输–send()与recv()功能：数据的发送与接收格式：intPASCALFARsend(SOCKETs,constcharFARbuf,intlen,intflags);intPASCALFARrecv(SOCKETs,constcharFARbuf,intlen,intflags);6、多路复用–select()功能：用来检测一个或多个套接字状态。格式：intPASCALFARselect(intnfds,fd_setFARreadfds,fd_setFARwritefds,fd_setFARexceptfds,conststructtimevalFARtimeout);参数：readfds:指向要做读检测的指针writefds:指向要做写检测的指针7、关闭套接字–closesocket()功能：关闭套接字s格式：BOOLPASCALFARclosesocket(SOCKETs);2.1.4Winsock程序通信过程1、无连接协议的套接字调用时序图，如图2.1所示图2.1无连接协议的套接字调用时序图2、面向连接的套接字的系统调用时序图，如图2.2所示图2.2面向连接的套接字的系统调用时序图2.2多线程编程2.2.1线程和进程进程（Process）是具有一定独立功能的程序关于某个数据集合上的一次运行活动，是系统进行资源分配和调度的一个独立单位[6]。程序只是一组指令的有序集合，它本身没有任何运行的含义，只是一个静态实体。而进程则不同，它是程序在某个数据集上的执行，是一个动态实体。它因创建而产生，因调度而运行，因等待资源或事件而被处于等待状态，因完成任务而被撤消，反映了一个程序在一定的数据集上运行的全部动态过程。线程（Thread）是进程的一个实体，是CPU调度和分派的基本单位。线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。线程和进程的关系是：线程是属于进程的，线程运行在进程空间内，同一进程所产生的线程共享同一内存空间，当进程退出时该进程所产生的线程都会被强制退出并清除。线程可与属于同一进程的其它线程共享进程所拥有的全部资源，但是其本身基本上不拥有系统资源，只拥有一点在运行中必不可少的信息(如程序计数器、一组寄存器和栈)。操作系统引入线程的概念还带来了许多的好处：（1）在进程内创建、终止线程比创建、终止进程要快；（2）同一进程内的线程间切换比进程间的切换要快，尤其是用户级线程间的切换。另外，线程的出现还因为以下几个原因：（1）并发程序的并发执行，在多处理环境下更为有效。一个并发程序可以建立一个进程,而这个并发程序中的若干并发程序段就可以分别建立若干线程,使这些线程在不同的处理机上执行。（2）每个进程具有独立的地址空间，而该进程内的所有线程共享该地址空间。这样可以解决父子进程模型中，子进程必须复制父进程地址空间的问题。（3）线程对解决客户/服务器模型非常有效。操作系统从单进程单线程发展到多进程多线程是必然的趋势，当年的DOS系统属于单任务操作系统，最优秀的程序员也只能通过驻留内存的方式实现所谓的”多任务”，而如今的Win32操作系统却可以一边听音乐，一边编程，一边打印文档。2.2.2线程通信与同步线程之间通信的两个基本问题是互斥和同步。线程同步是指线程之间所具有的一种制约关系，一个线程的执行依赖另一个线程的消息，当它没有得到另一个线程的消息时应等待，直到消息到达时才被唤醒。线程互斥是指对于共享的操作系统资源（指的是广义的”资源”，而不是Windows的.res文件，譬如全局变量就是一种共享资源），在各线程访问时的排它性。当有若干个线程都要使用某一共享资源时，任何时刻最多只允许一个线程去使用，其它要使用该资源的线程必须等待，直到占用资源者释放该资源[7]。线程互斥是一种特殊的线程同步。实际上，互斥和同步对应着线程间通信发生的两种情况：（1）当有多个线程访问共享资源而不使资源被破坏时；（2）当一个线程需要将某个任务已经完成的情况通知另外一个或多个线程时，在WIN32中，同步机制主要有以下几种：（1）事件(Event);（2）信号量(semaphore);（3）互斥量(mutex);（4）临界区(Criticalsection)。2.3Windows实时通信API微软实时通信（RTC）API是一套提供有丰富功能的核心组件[8]。这些性能我们可以在WindowsMessenger和其它使用实时通信API的应用程序中看到。MicrosoftWindowsXP中结合与增强了丰富的通信特性，为RTC体验提供了基础。MicrosoftWindowsMessager利用这些特性为用户到用户间的通信提供了实时语音和视频、实时消息和其它的协作功能。另外，其所提供的应用程序编程接口（APIs）使得这些丰富的通信特性可用于任何应用程序。1、音频视频编解码器的可获得性WindowsRTC客户端支持表3.1列出的音频编解码器(codec)，同时列出了相关的采样率和比特率。选择哪一种编解码器取决于通信双方的能力和带宽。例如，如果其中一方使用56KBps的拨号连接，那么G.711将被禁用，因为它超出了可获得的带宽限制。又比如，假设其中一方支持SIREN，而另一方不支持，那么首选的编解码器SIREN将被禁用。如果双方均支SIREN并且带宽足够，那么在所有的编解码器中SIREN即为首选。表2.1WindowsRTC客户端支持的音频编解码器Codec采样率比特率RTP包长度G.711Kilohertz(kHz)64kilobitspersecond(Kbps)20milliseconds(msec)G.722.116Khz24Kbps20msecG.7238Khz6.4Kbps30msec,60msecor90msecGSM8Khz13Kbps20msecDVI48Khz32Kbps20msecSIREN16Khz16Kbps20msecor40msecH.263是视频所支持的编解码器，其比特率在6KBps到125KBps之间不等。出于兼容性的考虑，H.261也是被支持的编解码器。该版本只支持OCIF（176×144）。不支持第三方编解码器的插件。2、回波抵消（AEC）AEC的工作原理是通过对讲话者的输出建模，并且将其从麦克风捕捉的信号里除去。AEC有助于确保对端听不到回声。为了启用AEC，在WindowsMessager中运行”音频和视频调节”向导（AudioandVideoTuning：进入菜单：Tools/AudioTuningWizard…）。在音频调节部分，去掉”Iamusingheadphones”复选框前面的”√”。使用IRTCClient接口PreferredAEC方法可以通过编程实现对AEC的启用和禁用。RTC客户端使用的AEC模块是MicrosoftDirectSound底层结构的一部分。该组件包括下列特性和限制：（1）AEC只在不超过25×15×9英尺的小房间才会有效；（2）AEC只对单声道有效，当输出是多个通道的立体声的时候，只有一个通道能够具有回波抵消的效果；（3）AEC不能抵消来自其它声音源的声音，比如背景中收音机放出来的歌曲；下面两条限制只应用于WindowsXP的RTMRTC客户端。可从WindowsUpdate下载一个包来去掉这两条限制。（1）AEC要求音频捕捉和再现设备使用同一个时钟，这意味着，AEC对USB音频设备无效。如果RTC的客户端检测到了这样的情况，音频调节向导中的那个复选框会被禁用，以阻止用户启用AEC。（2）AEC仅对采样率为8KHZ和16KHZ的信号有用。这意味着AEC对采样率为其它值的声卡无效，例如基于AC97的声卡，这种声卡的采样率在44KHZ左右。调节向导检测到这样的声卡时，同样也会禁用AEC。可在程序里通过IRTCClient接口的PreferredAEC方法对AEC进行控制。3、冗余音频编码冗余音频编码是一种补偿丢包的技术。RTC客户端实现了一种one-packet冗余算法。当该算法被启用的时候，每一个包都包含了当前的音频帧和前一个音频帧若某一个包丢失，接受者还有第二个机会在紧随其后的包里得到该音频帧。这个过程在IETFRFC2198中有文档说明。可被恢复的包的最大数目是3个。该算法根据实时通信控制协议（RTCP）所提供的信息进行自适应调节。该算法开始的冗余为0，随着丢包的发生引入冗余。原始数据包和携带原始数据备份的包的距离决定有多少个已丢失的包能被恢复。这一距离在1到3之间不等例如，假如距离为2，而丢失了第n个包，那么在第n+2个包中可以获得同样的信息。如果丢失了第n和第n+1个包，我仍然可以在第n+2和n+3个包中获得全部所有信息。如果我丢失了第n个、第n+1个和第n+2个包，那么第n个包的信息将无法重新获得（因为这些信息在第n+2个包当中）。表2.2说明在丢包率不同的情况下距离的取值。表2.2丢包率与距离的关系距离丢包率（低）丢包率（高）00514102915314204、动态抖动缓冲和调整抖动缓冲被用于通过缓冲音频包及调整其呈现，从而在接收的音频中进行平滑延迟变化处理。这样可以使语音更平滑地传输给用户。客户端可有一个能增大到500毫秒的抖动缓冲。换句话说，这个缓冲区可以吸收接收包中500毫秒的延迟变化，而不会引起语音的抖动。再现缓冲是一个两秒的循环缓冲。如果在一个很短的时间里我们得到了超过两秒的语音数据包，那么新收到的包将会被丢掉。在这一版本中，抖动缓冲在新的音频数据高峰进行重新调整。为确保高质量语音发送者应该为所有的编解码使用静音抑制。RTC的客户端默认使用静音抑制。5、自动增益控制（AGC）AGC是一种根据输入信号水平动态调整增益的机制。RTC客户端根据所捕捉到的音量调整麦克风的增益，以实现AGC。当音量（无论是捕捉到的音量还是再现的音量）超过某一门限值，信号就会被限幅。限幅指的是音频设备的输出不再随着输入而变化，输出实质上变成了最大音量位置上的一条水平线，这会引起声音的中断。当RTC客户端检测到音频增益达到了某一门限–每一个包的连续平均峰值的脉冲编码调制的值都超过了最大门限值–它会自动减小增益来避免限幅的发生。另一方面，如果捕捉到的音量太低（每一个包的连续平均峰值的脉冲编码调制的值低于最低门限值），RTC的客户端会提高增益。当然，增益的调整不会使音量超过用户在调节向导中设置的值。注意当启用AEC时增益不会被增大，因为这样会使得AEC重新聚合，而这需要几秒的时间。6、带宽估计实际可用带宽可能少于WindowsSocket所报告的本地连接速度。有很多因素会引起这种现象，包括通道的低速连接，其它应用程序消耗的带宽等等。为了估计实际可用带宽，RTC客户端发送连续不断的RTCP包。另一端根据包与包的延迟来估计带宽。最初每一个RTCP包的报告都用于估计带宽，然后逐渐减小到每三个包中的一个用于估计带宽。当前，带宽估计的结果可用于指示连接是否是LAN，并且被用作计算实际可用带宽的上限。以后，这一算法将扩展到能给出更多具体的结果。7、质量管理算法RTC媒体的质量管理的目标是在不同的网络环境中，通过RTC客户端为用户提供更好的音频视频服务。QC持续监控网络环境，计算输出流的可用带宽，动态改变音视频输出流的设置，以提供更平滑的流输出、最小的抖动和延迟。在音视频输出流之间，QC为音频提供更高的优先级。QC收到来自以下三个源之一的命令或者事件的时候，对输出流进行调整：应用程序、远端和实时通信传输协议（RTP）模块。应用程序通过增加去除流或者改变最大比特率的设置来触发对输出流的调整。远端通过发送新的SDP（会话描述协议）来触发调整，这反过来也会引起流和比特率的设置。RTP模块周期性地发送RTC媒体事件来报告对端的估计带宽和丢包率。通过接收这些事件，QC对音频和视频流进行调整。2.4IP组播技术80年代开始，Stanford大学实施了第一项多目通话，1992年IETF定义和发布了一个多播的网络标准，用于建立多播主干网，即在Internet上运行的单路广播和多播综合网络，并且很快便名声远扬。1995年，Cisco公司和Lucent公司开始销售支持多播的路由器和交换机，一年后依赖多播的应用产品开始上市。随着Internet/Intranet/Extranet的发展，各种多媒体通信业务也得到了广泛的应用，特别是网络音频和视频应用正是当前研究、开发和实现的热点，大多应用都是基于多播技术的[9]。例如:美国波士顿银行采用多播技术在以太网上向250个贸易商行和其他部门分发市场数据。对于IPv4有三种基本地址：单址广播(unicast，简称为单播)，广播(broadcast)和多址广播(multicast，简称为多播或者组播)。一个单址广播地址是将一个包传输给唯一的一个目的地，一个广播地址是将一个报文传递给整个子网，而一个组播地址是将一个报文传递给属于某一个集合的主机，这些主机同属于一个多播组，它们可位于不同的子网上。组播组(MulticastGroups)的含义为:单个主机可以自由地在任何时候加入或离开组播组，组播组没有物理位置或数目大小的限制，一个主机可以在同一时刻属于多于一个的组播组，也没有要求必须给所属的组播组发送报文。组播不是基于面向连接(connection-oriented)的，一个组播包都是以相同的”尽力而为”(best-efort)的方式传递给目的组成员的，同标准的单址广播的投递方式。这意味着组播数据包即不被保证能够到达每一个组成员，也不被保证包的传递顺序不会被打乱。IP组播采用D类地址，地址范围为224.0.0.0到239.255.255.255。为了参加与本地网络上的IP组播，主机必须使用允许收发多播数据的机制。当跨越多个网段时，必须由本的组播路由器和其他组播路由器联系传送组成员关系信息，建立组播路由。这些就要靠因特网组管理协议IGMP(IntemetGroupManagementProtocol)来实现，IGMP来自SteveDeering的博士论文中的主机成员关系协议IGMP中。这里我们概括一下IGMP的工作原理。IGMP的工作过程分为两个阶段。第一阶段：当主机加入一个新的组时，它发送一个IGMP报文给全主机组播地址，宣布这个成员关系成立，本地组播路由器接收到这个报文之后，向互联网上的其它组播路由器传播这个关系信息以建立必要的路由。第二阶段：为适应动态的成员关系，本地组播路由器周期性地轮询本地网络上的主机，以便确定现在的各个组中有哪些主机。如果经过若干个轮询后某个组中始终没有成员，组播路由器就认为该组中不再有本网络中的主机，于是停止向其他组播路由器通告该组的成员关系信息。IP组播的机制目前流行有多种，我们概括如下：第一种，距离向量组播路由协议(DVMRP)。DVMRP是Mbone上广泛使用的多点路由协议，发送者和接收者之间建立一个基于发送者的组播树，开始从发送者出来的数据包被送到各个组播路由器(称为MCR,multicastrouter),MCR为每个源维持一个最佳路径，当MCR收到一个组播数据包时，若是从该源的最佳路径来的则转发给其它MCR，否则丢弃。第二种，组播开放最短路径优先(MOSPF)。MOSPF是一种基于链路状态的路由机制。通过使区域中的所有MCR都有一致的区域拓扑结构图和组成员的分布表。当MCR收到一个组播数据包后，用Dijkstra算法求出到所有接收者的最短路径，再将数据包从最短路径的端口转发，与DVMRP相比，MOSPF是按需并从最短路径转发，因此路由性能大大提高。第三种，基于核的数(CBT)。CBT是基于多目组来建立组播树，令一个MCR作为树的核心，称为核心MCR。当MCR所在子网或其下游子网上有主机加入多目组时，MCR与该组的核心MCR取得联系，以核心MCR为根按最短路径建立组播树。第四种，与协议无关的组播(PRTC)。PRTC机制融合了基于核和最短路径树状态的特点。为了提高组播的效率，PRTC定义了两个模式:密集模式和稀疏模式。密集模式的含义是在组所覆盖的区域中，该组成员的子网数量在子网总数中占有很高的比例。可以采用反向确认方式来有效建立组播树。密集模式基本上与DVMRP相同，属于数据驱动型协议.稀疏模式的含义是拥有组成员的子网数量远小于互联网中网络数量或组所覆盖的网络资源不足。因此此种模式需要限制不必要的数据包投递以提高通信效率。IP组播的优点主要体现在三个方面，(1)节省带宽：与点对点的传输方式不同，不需要发送者给每一个接收者都发出相同的数据，而仅是由组播路由器复制后进行分发，这样就减少了带宽要求：(2)服务器负载降低，因为一些数据包的分发工作由组播路由器完成了；(3)网络负载降低，原因同节省带宽的理由。当然还是有不足之处的，(1)不可靠的信息包传送，因为组播使用的是UDP。而UDP是一种不可靠的数据传输方式；(2)信息包的复制，这也是单播与多播的关键差别，路由器主动地发送组播信息包的拷贝到多个接口，则增加了多个拷贝的组播信息包到达某一种接收点的可能性；(3)网络阻塞，该种情况主要出现在欲传送的信息流的带宽要求超过实际链路所能提供的带宽，由于IP组播没有内建的阻塞避免机制从而引起的阻塞。第三章局域网实时通信系统的实现3.1系统功能描述与模块划分3.1.1系统功能描述本课题是针对目前网络环境实时通信的应用要求，开发一个能支持视频和语音通信的局域网实时通信系统。其主要的功能是：1、允许多人的实时通讯2、系统通过Winsock实现信息交流3、支持视频和语音通讯4、接受注册，并允许注册用户登录5、能够进行点对点的通讯和文件传输6、能够实现广播功能3.1.2系统模块划分1、注册登陆模块本模块完成新用户的注册信息存储、登陆验证和数据库的管理功能[7]。该模块通过ODBC对access数据库的操作，将用户的注册信息写入到access数据当中。在用户登陆的时候，将登陆信息与数据库查询比较，确认是否是已注册的用户。另外，在此部分中还加入对了对聊天服务器的控制按钮，以方便以注册登陆为主的服务器更好的控制整个系统。2、客户端模块本模块是整个系统的核心部分，也是用户直接面对部分。根据其完成的功能可以划分四个子模块，分别是注册子模块、登录子模块、聊天子模块和文件传送子模块。在这部分模块当中，还有一个比较重要的功能就是对视频语音模块和组播通信模块的控制。客户端采用winsock通信模式，在程序运行后的第一个对话框，客户可以选择登陆或注册，若是注册则启动注册向导，分三步完成注册工作，点击确定后，客户端将与指定的IP地址和端口号去连接注册登陆模块，成功连接后注册登陆模块执行注册操作，并返回注册结果。客户注册成功后，即可用注册时的用户名和密码进行登陆，将登陆信息按注册时的网络设置发往服务器，服务器执行登陆操作并返回注册结果，登陆成功则连接聊天通信模块，否则退出程序。登陆成功出现聊天对话框，可以从下拉组合框选择好友，在文本框内编辑信息发送给好友，聊天通信模块收到信息后依照接收者用户名进行转发。若客户收到信息则闪动托盘处的图标，提示用户收到信息，用户可以点击回答进行回复。当登陆成功后，用户也可以在选择好友后点击传送文件按钮来进行文件传送。另外，用户还可以点击语音视频按钮、组播通信按钮来分别启动视频语音模块和组播通信模块。3、聊天服务器模块本模块负责完成数据转发以及共享数据结构的管理。本模块设计为无界面进程，并采用共享数据结构，为每个客户端创建两个线程，实现接收和转发的功能。一个线程用于发送，一个线程用于接收。4、语音视频模块本模块负责语音视频功能的实现[8]。通过客户端模块的视频通信按钮可以启动本模块。模块采用windows平台下的实时通信API来实现语音和视频通信，避免了视频捕捉–数据编码压缩–数据传输–数据解码–视频显示这个复杂的过程，简化了整个程序。5、组播通信模块本模块主要实现的是组通信，当用户点击客户端上的”组播通信”按钮时，将进入通信组。进入通信组以后，通信组中的任何一个成员发送信息时，所有的成员都可以接受到信息。这样就可以可以形成一个讨论组，以解决点对点通信的单一性。3.2系统结构图图3.1本课题系统结构图3.3模块功能的实现本课题采用的是Visualc++6.0平台进行软件设计。本节将详细介绍各模块跟功能的实现过程。3.3.1注册登陆模块功能的实现注册登陆模块采用面向连接的并发式方式，模块设计成为一个对话框程序[10]，其运行界面如图3.2所示。调用WSAStartup初始化动态库，socket函数创建套接字，bind函数绑定本地IP地址和端口，listen函数使套接字进入侦听，然后由于调用accept()函数将产生阻塞，所以不宜在主线程中调用该函数，因而在初始化网络后当用户按下”运行注册登录服务器”按钮后，利用侦听套接字启动注册登录线程RegLoad(voids)进入无限循环，在线程中调用accept()函数，用来接受来自客户端的连接请求，每当一个连接请求到来时，accept()函数将产生一个新的套接字，利用这个套接字产生一个新的线程talkToClient(voidcs)与客户端进行通信并读写数据库，通信完毕后关闭该套接字和线程，原来的侦听套接字继续处于侦听状态。图3.2注册登陆模块实验结果图在对话框初始化的同时完成网络初始化，即执行Init_net()函数接下来我们看看本模块是怎么对数据库进行操作的，以及对客户端发送过来的注册或登陆信息的处理方式。首先要建立应用程序与数据库，以及表的连接：其代码如下：CStringCUser::GetDefaultConnect(){return_T(”ODBC;DSN=wbQQuser”);}CStringCUser::GetDefaultSQL(){return_T(”[表1]“);}紧接着提取出客户端发送过来的信息，根据接收到数据的前几个字符来判断消息的类型是注册还是登陆。如果是Reg则表示注册，Load则表示登陆。当发送过来的是注册信息的时候，首先提取出用户名，然后和表中已存在的用户名进行比较，如果存在的返回”exist”信息，并关闭线程。如果不存在，这进行数据库操作，将发送过来的注册信息添加到数据库当中。当发送过来的是登陆信息的时候，则将用户名和密码信息与数据库里面保存的信息进行比较，相同则允许登陆。1、注册登陆模块流程图：图3.3注册登陆模块流程图3.3.2客户端模块功能的实现客户端模块比较复杂，这里将分为注册子模块、登陆子模块、聊天子模块、发送文件子模块来介绍。首先，为了让客户端和服务器能够协同工作，必须在通信过程中定义一套规则也就是网络通信协议，让双方能够相互听懂，并依照协议执行相应的功能块[11]。客户端注册时发送的消息为Reg:+BasicDlg.m_strUserName+BasicDlg.m_nAge+sex+BasicDlg.m_strPassWd+MiscDlg.m_strTruName+MiscDlg.m_strCity+MiscDlg.m_strEmail+res+MiscDlg.m_strTel，注册时发送消息的头部为Reg。登陆时发送的消息为：Load:+m_strUserName+m_strPassWd，登陆时发送消息的头部为Load。登陆成功后，客户端将自己的用户名发送给聊天通信服务器，服务器为客户端创建一个套接字，两个线程，并填充socketInfo结构，连入链表。客户端发送消息结构为：”接收者用户名”+“：”+“发送者头像ID”+“~”+“（星期、月、日、年、时、分、秒）”+””+”发送者用户名”+”->”+“接收者用户名”+””+“发送的消息”，其头部均为接收者用户名，服务器依照用户名查找链表，截掉头部后把原信息进行转发，若客户端关闭，则发送消息为”Close!”，服务器从链表中删除相应项。客户端可能收到的消息有三种，第一种为普通消息，结构如前所述；第二种为”SendFile!”，表示对方想向己方传送文件；第三种为”Refuse！”，表示对方拒绝接收己方文件。1、注册子模块注册子模块相对来说比较简单，只需要把用户填写的用户信息按上面介绍的顺序发送到注册登陆服务器去处理，其他的活动它不需要参与。所以，这里也不做过多的介绍。只是需要说明的一点的是，注册信息中有一项是网络设置。在这里需要设置登陆注册服务器和聊天服务器的地址，当填写完成以后，将在本地生成一个net.cfg文件。这个文件非常重要，下次登陆时，就是根据这个文件的设置来连接服务器。注册子模块注册向导界面如图3.4所示，运行结果如图3.5所示。图3.4客户端注册登陆子模块部分实验结果图图3.5客户端注册登陆子模块部分实验结果图2、登陆子模块登陆子模块也只需要把用户名和密码信息按照自定义协议的格式发送给登陆注册服务器，然后由服务器来处理。用户名和密码正确，则登陆成功。其客户端界面如图3.6所示。图3.6客户端登陆子模块实验结果图3、聊天子模块聊天子模块是客户端最重要的一个模块。登陆成功以后，即进入客户端主界面，主界面如图3.7所示。用户可以在下拉菜单中选择聊天的对象，然后文本框中编辑信息，按”发送”键发送。子模块设定了一个用于接收数据的RecvThread(voidcs)线程。图3.7客户端聊天子模块实验结果图RecvThread函数代码如下：UINTRecvThread(voidcs){提取信息中”：”以前的信息，用于判断消息类型；判断接受到消息的类型；if消息类型为SendVido!{获取发送者用户名；显示提示框，是否接受对方的请求与对方进行视频通信；if(同意对方请求){启动视频通信模块；获取本地IP地址；发送本地IP地址给视频请求者；}Else不同意对方的请求{发送拒收请求消息；}continue;}//////////////////////////////////////////////////////////////////////////////////if消息类型为SendFile！/对方要给我发送文件{获取发送者用户名；显示提示框，是否接受对方的请求与对方进行文件传输；if(同意对方请求){开始接收文件线程}Else不同意对方的请求{拒绝接受文件；}continue;}if消息类型为拒绝//对方拒绝接收文件{显示对话框，提示对方拒绝你的请求；}}4、文件传输子模块传输文件某种程度上来说是依托于聊天子模块的。客户端A想给客户端B传送文件，则发送消息为”SendFile!”，B收到”SendFile!”后弹出消息框，提示对方向己方传送文件，接收按”是”，执行文件接收功能；拒绝按”否”，发送”Refuse!”其运行结果如图3.8所示。图3.8客户端传输文件子模块文件发送端流程图当对方接受到请求信息后，执行如下代码：（此部分代码时前面所介绍的RevThread()函数中的一部分）UINTRecvThread(voidcs){If对方要给我发送文件{获取发送者的用户名；显示对话框，提示是否接受文件；if同意接受文件开始接收文件线程}else{发送拒收文件消息}}If对方按下”拒绝”按钮{显示对话框，提示对方拒绝接受文件关闭发送文件线程；}当对方同意接受文件以后，客户端A选择需要发送的文件，然后开始发送文件。发送完文件名信息以后，暂停。客户端B选择保存文件的路径，然后再继续传送文件。文件传送完毕以后，跳出对话框，提示操作完成。运行结果如图3.9所示图3.9客户端传输文件子模块实验结果图传输文件模块设定了两个线程，一个用于接收、一个用于发送–UINTrecvFile(voiddata)、UINTsendFile(voidname)。通过这两个线程来实现文件的接受和发送。（1）传输文件子模块流程图，如图3.10所示。图3.10客户端传输文件子模块文件发送端流程图（2）文件接收端程序流程图，如图3.11所示。图3.11客户端传输文件子模块文件接收端流程图3.3.3聊天服务器模块功能的实现聊天通信服务器设计为无界面的进程，创建时先建一个基于对话框的应用程序，然后把对话框类删除，把APP类里面与对话框有关的语句全删，就建立了一个无界面的进程。本模块是整个系统实现的关键，它运用共享数据结构技术及多线程技术，通过I/O端口56790与用户端连接，实现了数据转发功能。首先，程序初始化网络Init_net()，接着当用户连接到服务器时，创建接收线程和发送线程，这样就可以实现数据转发[12]。最后，当用户断开连接时，服务器关闭与他的连接，并结束相应的线程。1、共享数据结构本模块的共享数据结构一共有两个，即socket_info和send_info。前者包含了所有登陆用户的一些基本资料，后者则包含了当前服务器接收到的用户端所发送的信息资料。详细内容及注释如下：structsocket_info{SOCKETs_client;//用户的SOCKET值u_longclient_addr;//用户网络地址CStringpet;//用户昵称CWinThreadthread;//为该用户创建的发送线程对象的指针};structsend_info{CStringdata;//用户端发送的数据内容（经过编辑）CWinThreadthread;//需要发送数据的任务指针};在程序中，定义两个全局变量，用来在线程间共享：send_infoinfo_data;CLists_info;每当有用户连接到服务器，服务器就将用户端的一些信息以socket_info结构体的形式存入s_info列表中；而当服务器接收到用户端发送过来的数据时，就将数据格式化后存入结构体info_data，通过与结构体列表比较，确定需要恢复的发送线程（所有发送线程在创建时都被挂起）。这样，服务器就准确地转发了数据。2、多线程每当服务器上有用户连接成功，服务器都会为其创建两个线程：接收线程（RecvData）和发送线程（SendData），并且接收线程在创建后处于可执行状态，而发送线程则阻塞，等待服务器将其唤醒。这两个线程都执行一个无限循环的过程，只有当通信出现异常或用户端关闭连接时，线程才被自身所结束，并且，这两个线程一定是同时生成，同时结束的。很显然，每个连接产生两个线程使得数据转发变的简单，但同时又使得服务器的任务加重。因此，用户端的连接数量有所限制，视服务器软、硬件能力而定。同时，由于多线程对结构体info_data都需要操作，所以线程间必须同步。这里定义了互斥量CMutexm_mutex，用它的方法Lock()和Unlock()来完成同步。3、聊天模块流程图，如图3.12所示图3.12聊天通信模块流程图3.3.4语音视频模块功能的实现1、实时通信客户端接口需要的头文件：rtccore.h增强功能的应用程序获得带有使用CLSID_RTCClient的CoCreateInstance()的实时通信客户端接口。一旦这个接口可用，Initialize()这个COM对象来判断这个平台的通信会话性能。//初始化RTCCOM对象hr=CoCreateInstance(CLSID_RTCClient,NULL,CLSCTX_INPROC_SERVER,IID_IRTCClient,(LPVOID)&m_pClient);//初始化客户端接口hr=m_pClient->Initialize();2、选择通信类型下一步是选择偏爱的通信和相关设备（摄像头和麦克风）的类型。缺省设置情况是能使用所有的通信类型。如果通信会话的参与者能够共享应用程序、传递实时消息、声音的和视频，这些性能都能够自动的可用。如果一个参与者不支持某种特定的通信类型，那么对于所有的会话参与者来说，这种通信类型也是不可用的。m_pClient->SetPreferredMediaTypes(RTCMT_ALL,VARIANT_TRUE);视频：Windows实时通信客户端在1/4CIF图象格式（176×144）分辨率下支持H.261和H.263编解码器。这些可变比特率编解码器发送界于6-125Kbps的视频数据。使用IRTCClient接口方法put_MaxBitRate和put_TemporalSpatialTradeOff可能影响目标的视频转换的空间时间分辨率。音频：Windows实时通信客户端支持许多种音频编解码器。音频编解码器是基于终端的连接质量而定的。3、初始化一个会话在应用程序能够与其它参与者连接之前，它必须能够处理在会话期间实时通信fireoff的事件。在PC到PC的通信中，应用程序捕获实时消息、音量强度、媒体、客户端消息和会话状态改变等事件。下面的代码说明了如何只创建一个事件过滤器来捕获特定的RTC事件类型。lEventMask设置了应用程序感兴趣的一组事件。（如果想要得到一个完整的事件列表，请在MSDN网站上搜索RTC_EVENT以便取得每个事件的详细信息）。CRTCEvents类为附属的客户端发送事件。RTCEvents对象在应用程序和RTCEventNotification接口之间创建一个接口。所有的实时通信事件将由RTCEvents类处理。在一个会话期间，音频与视频媒体类型可以被添加也可以被删除，所以客户端必须监听这些事件类型。4、处理实时通信事件一旦事件处理器被RTCEventNotification接收端注册，那么接收和处理实时通信事件就非常简单了。当实时通信事件被样例应用程序接收的时候，应用程序的事件处理程序发送一个消息到这个应用程序的消息处理程序。OnRTCEvent()函数处理所有的由应用程序接收的所有的不同类型的事件。5、创建一个通信会话在能够使用实时通信之前，必须创建和初始化一个通信会话。然后你就可以输入参与者的IP地址来开始通话了。也可以通过输入一个电子邮件地址或者一个电话号码来激活一个通信会话。然而，这个函数需要SIP注册服务器，这在本文讨论范围之外了。我们将在下篇文章中谈谈这个话题。实时通信不支持多个视频会议会话同时运行，所以这个应用程序在初始化一个新的会话之前，必须首先检验目前没有运行视频会议会话。在第一个发行版本中Windows实时通信客户端只支持多个电话到电话的通信会话，而不支持多个音频与视频或者只有音频的会议。为了与另一台计算机通话，需要识别实时通信会话类型并创建一个使用IRTCSession接口的会话类型。下面的代码说明如何创建会话。6、结束会话为了结束一个通信会话，所有运行的应用程序必须被关闭。然后实时通信客户端接口调用ShutDown()和完成结束通信会话的过程。其运行的实验结果如图3.13所示图3.13视频语音通信子模块实验结果3.3.5组播通信模块功能的实现组播通信模块没有服务器客户机的区分，每个客户都要维护一些信息，如在线列表等。为了实现组播通信的功能，首先自我定义一些简单的协议，也就是明确消息的种类。这里定义了四种消息类型：constenum{MT_JION=1,//一个用户加入MT_LEAVE,//一个用户离开MT_MESG,//一个用户发送消息//内部使用，告诉新加入的用户自己的用户信息MT_MINE};只要有成员加入或者离开这个组，MT_JION或者MT_LEAVE封包就会被发送到组，以便所有的成员都可以跟踪在线的成员。其运行结果如图3.14所示。图3.14组播通信模块实验结果图当有用户（假设为用户X）启动了组播通信模块加入到组通信当中时，在系统消息一栏就会提示组通信中的所有用户，”用户X加入”。同时，在下拉列表框中也会自动添加上用户X。用户可以选择单选按钮”面向组”或者”面向用户”来选择是向组内所有用户发送信息还是仅仅向下拉列表框中的用户发送信息，当选择面向用户发送信息的时候，其他用户是无法收到信息的。本模块中定义了一个CGroupTalk类，CGroupTalk类有自己的线程来接受组封包，它创建了两个套接字-m_sSend和m-sRead，一个用于发送数据，一个用于接收数据。类的构造函数初始化各个成员变量，然后创建内部工作线程_GroupTalkEntry，类的所有工作都是在线程中完成的。最后提供给用户的发送消息的函SendText。组播通信模块流程图，如图3.13所示。图3.13组播通信模块流程图第四章总结与展望4.1实践结果分析经过这段时间的毕业设计，对整个局域网实时通信系统的开发流程有了一定的了解，通过实时通信的研究，构建了五个通信模块并将其应用在系统当中。本次设计以windows作为开发环境，采用C++开发工具，在相关网络编程设计实例的基础上，结合自己对实时通信系统的研究，建立了能支持语音和视频通信等功能的实时通信系统。针对多媒体的网络传输要求，系统对数据包的丢失率具有一定的容忍度，对传输时延却有很高的要求，系统不希望因为重传数据包而增加网络的传输时延。因而在传输协议上选择了UDP，其对于整个系统的效果来具有决定性意义。本课题需要构建的实时通信系统具有5大功能：注册/登陆，聊天，文件传输，视频/语音，组播通信。为了实现上述的功能，经过一个多学期的研究，以及在老师和同学的帮助下构建了这样一个功能繁多的实时通信系统。论文主要完成了一下的工作：1、利用ODBC数据库编程和winsock通信结合的方式，从而实现了客户端的注册和登陆验证功能。达到用户身份验证的目的。2、使用多线程和共享数据结构技术，实现了多用户之间的通信以及聊天通信模块的转发功能，这保障了多个用户通信能够互不干扰的。3、使用windows实时通信API实现了视频和语音通信的目的。本身视频语音是一个庞大而又复杂的工程，依照原始的通过视频捕捉-视频压缩编码-数据传输—视频解码-视频显示方法，短期内完成的难度太大。而采用了实时通信API将其过程都交由系统来解决，简化了整个实现过程。4.2展望局域网实时通信系统的设计与开发包含了许多方面的内容，论文所作的工作是非常有限的。尽管目前各个功能基本上都得到了实现，但很多不完善的地方还是存在的。根据这些不足，首先需要做如下改进：1、美化界面。虽然功能得到了实现，但是在客户端这一块的界面效果上还不是很美观，还没有达到赏心悦目的感觉。2、加强点对点通信功能，目前的点对点通信只能通过从下拉列表中选择聊天对象，实现不了类似QQ那样，与每个对象的通信都建立单独的对话框。3、构建多个通信组。当前还只能够建立一个通信组，这就进行组播通信的对象，有了一定的约束性，用户无法选择进入不同的组。参考文献[1]上海敏树信息技术有限公司.即时通信概述[EB/OL].http://www.smart-tree.com.cn/zsk_02.htm.2007-04-05.[2]DouglasE.Comer,DavidL.Stevens著,赵刚,林瑶,蒋慧,等译.用TCP/IP进行网际互联第一卷：原理、协议与结构[M].北京:电子工业出版社,2001.[3]DouglasE.Comer,DavidL.Stevens著,赵刚,林瑶,蒋慧,等译.用TCP/IP进行网际互联第二卷：设计、实现与内核[M].北京:电子工业出版社,2001.[4]吴国勇，一种基于IP网的多媒体实时传输方法的研究和实现[D]:[本科论文].重庆：重庆邮电大学，2005.[5]DouglasE.Comer,DavidL.Stevens著,赵刚,林瑶,蒋慧,等译.用TCP/IP进行网际互联第三卷：客户-服务器编程与应用[M].北京:电子工业出版社,2001.[6]乔林杨志刚.VisualC++高级编程技术MFC与多线程篇[M].中国铁道出版社.1999-10.[7]费晓琪,孟庆丰.Microsoft.Net平台上用远程对象模型实现远程监测映像节点[J].计算机工程与应用,2003,39(7):141～143.[8]WAYNE.Micosoft实时通信API多媒体支持慨述.[EB/OL].http://www.yesky.com/403/1704403.shtml.2007-05-01.[9]罗明宇陶孜谨卢锡城，rtp在网络视频传输中的实现研究[J]，《计算机工程》2000.9.[10]陈旭东,周华春.基于注册服务的网络管理研究[J].计算机工程与应用,2003,39(9):144～145.[11]胡志刚,阎朝坤.基于网格的现代协同设计方法[J].中南大学学报:自然科学版,2004,35(6):988～992.[12]BrunoR.Preiss.DataStructuresandAlgorithmswithObject-OrientedDesignPatternsinC++[M].JohnWiley&Sons.Inc，1999.[13]NicolaiM.Josuttis著，侯捷/孟岩译.C++标准程序库[M].武汉：华中科技大学出版社，2002.[14]Whlisch,HansL.CyconandMarkPalkow著,MobilitySupportVideoRTC[C].Berlin:ComputerCenter,FBIngenieurwissenschaften.2005.[15]丁柯,金蓓弘.通用网络编程接口包的设计和实现[J].小型微型计算机系统,2003,24(1):5～9.',)