logo资料库

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

第1页 / 共24页
第2页 / 共24页
第3页 / 共24页
第4页 / 共24页
第5页 / 共24页
第6页 / 共24页
第7页 / 共24页
第8页 / 共24页
资料共24页,剩余部分请下载后查看
随着计算机网络技术的高速发展,多媒体信息通信已经上升到了一个更高的程度 -实时性。由此产生了一个新的名词,实时通信。相对于传统的电话、E-mail 等 通信方式来说,实时通信不仅节省费用,而且效率更高。 论文给出了能够支持登陆注册、点对点文件传输、视频语音通信、多用户聊天等 功能的局域网实时通信系统的设计与实现。在实时通信中,特别是多媒体的实时 传输中,对传输时延有非常高的要求。针对这一特点,整个系统采用 UDP 作为传 输层协议,因而在很大程度上减少了因重传造成的时延,同时也减轻了由此造成 的网络带宽损耗。其次,设计并采用多线程和共享数据库技术,实现了多用户聊 天的功能,使相互之间能够独立的通信。最后,在语音和视频通信的功能的实现 上,采用了 windows 系统提供的 windows RTC(real-time communication,实 时通信)API。Windows RTC API 为任何基于 Microsoft Windows XP 的应用程序 提供了卓越的基于个人计算机的通信性能–即时消息、音频与视频会议、应用程 序的共享/协作。采取这样的方法,简化了实现过程,也丰富了程序的功能。 本课题以 windows 作为开发环境,采用 C++开发工具,在相关网络编程设计实例 的基础上,建立了能支持语音和视频通信等功能的实时通信系统。 关键词:实时通信 多线程 文件传输 语音/视频 Winsock 摘 要 I ABSTRACT III 第一章 绪论 1 1.1 本课题研究的目的和意义 1 1.2 实时通信的发展及现状 2 1.2.1 实时通信发展历史 2 1.2.2 实时通信发展趋势以及发展过程中需解决的问题 4 第二章 WINSOCK 通信实现概述 6 2.1 WINSOCK 通信原理 6 2.1.1 TCP 和 UDP 6 2.1.2 客户机/服务器模式 7 2.1.3 WINSOCK API 主要函数简介 8 2.1.4 WINSOCK 程序通信过程 9 2.2 多线程编程 10 2.2.1 线程和进程 10 2.2.2 线程通信与同步 11 2.3 WINDOWS 实时通信 API 12 2.4 IP 组播技术 15 第三章 局域网实时通信系统的实现 18 3.1 系统功能描述与模块划分 18 3.1.1 系统功能描述 18 3.1.2 系统模块划分 18 3.2 系统结构图 19 3.3 模块功能的实现 20 3.3.1 注册登陆模块功能的实现 20
3.3.2 客户端模块功能的实现 22 3.3.3 聊天服务器模块功能的实现 28 3.3.4 语音视频模块功能的实现 30 3.3.5 组播通信模块功能的实现 32 第四章 总结与展望 35 4.1 实践结果分析 35 4.2 展望 35 致 谢 37 参考文献 37 附 录 37 摘 要 ABSTRACT With the computer network technology high speed develops,multi-media infor- mation communication already rises having arrived at a higher degree–real-time. From this, it has produced a new noun– real-time-communicate. Not only real time communicates economize cost, but also efficiency is higher. The thesis has given out design and realization being able to support functional local area network real time communicate system such as landing logon , point to point file trans- mission , video/voice communicate , multi-user chat. In real time transmission, especially in many mediums real time transmission, it has the very good request to transferring time delay. Transfer layer of agreements specifically for this one characteristic, entire system adopt UDP to accomplish. As a result to a great extent, have decreased by the time delay bringing about because of weight biography, at the same time also has lightened the network bandwidth spoilage bringing about from this. Secondly, design and adopt a multi-thread technology and share a database, have realized multi-user chat function. Because of this technology, communication is able to be independent between each other. Functional realization in video/voice communication, commonly used is uses a series of steps that are the video capture, the video compression, the data transmission, the video frequency decoding, the video show. The system gave up this complex way change to windows RTC (real-time-communication) API which the windows system provided. Adopted such method while to simplify realization process, the realization result also obtained the guarantee. This topic takes windows as the development environment, uses the VC++ develop- pment kit, in the correlation network programming design example foundation, establish- hed has been able to support function the and soon pronunciation and video communi- cation real-time communication system. Keywords:Multi-thread real-time-communicate file-transmission voice/video Winsock 第一章 绪论
1.1 本课题研究的目的和意义 近十多年来电信业和互联网的突飞猛进显然是一场行进中的革命,它们合力推动 着人类社会进入信息和体验经济时代。这场革命不仅正空前地革新着人们的通讯 和沟通方式,大大提高社会生产与企业运作效率,而且给整个社会的诸多方面带 来深层次的影响和冲击,导致了社会文化和价值观的嬗变,引发了产业变革,促 进了新兴行业的诞生,并带动了相关产业的迅速成长。 实时通信(RTC,real-time communication)即是这场革命的产物之一。它是一 种使人们能在网上识别在线用户并与他们实时交换消息的技术[1]。实时通信源 自 ICQ。四位以色列籍年轻人在 1996 年 7 月成立了 Mirabilis 公司,并于同年 11 月推出了全世界第一个实时通信软件 ICQ(目前 ICQ 已经归 AOL 旗下所有), 意为”我在找你”–”I Seek You”,简称 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(AOL Instant Messenger)。IT 业的巨头微软公司则于 1999 年 7 月发布了自己的 RTC 产品:MSN Messenger。而 Yahoo 则于 1999 年 6 月推出自己的 RTC 产品:Yahoo Messenger。在中国,深圳腾讯公司 1999 年 2 月推出了 RTC 产品 QQ,至此 RTC 行业的竞争格局基本形成。 本阶段的 RTC 产品处在一个突破技术瓶颈,保持 RTC 通讯的稳定性为主的阶段。 此阶段世界各国的网络接入都处在拨号上网向宽带过渡的阶段,RTC 用户经常断 线,通讯质量不稳定,很多时候 RTC 服务器必须承担中转实时消息的任务,同时
用户数的爆炸性增长对于 RTC 系统的性能和效率提出了很大的挑战。 2、产品应用期的 RTC(2001 年-2004 年) 2000 年之后,RTC 厂商的用户圈地运动逐渐完成,各个厂商都在寻找 RTC 产品的 赢利模式,他们发现仅仅依靠简单的文字实时交流和在线感知功能几乎不可能向 用户收费,事实上任何一家厂商如果对用户注册使用其 RTC 产品收费的话,用户 马上就会流失到提供免费服务的竞争对手那里去,ARTC、Yahoo Messenger、QQ、 MSN、ICQ 是几家主要的厂商,事实上各个国家还有大大小小数十家小厂商,竞 争非常激烈。 为了打破这个困境,在美国 MSN Messenger 采取了绑定微软自身的门户网站 (www.msn.com)的模式来赢利,用户在 MSN Messenger 中就可以点击新闻链接 从而自动启动系统默认浏览器到 MSN 门户网站进行浏览,还可在 MSN Messenger 中输入关键字提交到默认的搜索引擎站点后启动浏览器显示搜索结果,同时为提 高用户对 MSN Messenger 的黏性,微软在 MSN Messenger 中加入了其他更丰富的 应用:点对点的文件传输、视频/音频对话、与移动电话集成等,所有这些应用 都超出了 2000 年之前 RTC 产品的标准模式,使得 RTC 向多媒体、内容服务和移 动应用方面发展。 同样,Yahoo Messenger、QQ、ICQ 和 ARTC 都在发展各自的客户应用,从大方向 来看,都和 MSN Messenger 一样往多媒体、内容服务和移动应用方面发展,但由 于每家运营商的背景不同,导致各自的应用重点不同,例如 QQ 在手机短信、移 动设备方面的优势在全球范围内都比较独特,导致其赢利主要来自于手机短信收 费。而 ARTC 和 ICQ 由于其运营商 AOL 是美国最大的互联网接入服务商(ISP: Internet Service Provider),因此其收入并不直接来自 RTC 产品本身,而是 通过用户使用 RTC 产品时带来的互联网接入服务收入来赢利,Yahoo Messenger 的赢利模式和功能特点与 MSN Messenger 很类似,甚至其用户群体有相当的重合, Yahoo 主要是想通过 Yahoo Messenger 来提高其门户网站的访问量,而 Yahoo 作 为美国第一大门户站点,其赢利模式已经比较成熟,即收入主要来源于广告。 这个时期由于产品应用开始成型,导致每个产品的业务模式逐渐固定下来,各个 产品的用户定位也开始逐渐清晰,如 QQ 在中国主要定位在 30 岁以下的年轻人, 代表着一种时尚,而 MSN Messenger 在中国主要定位于办公室中的商务人士,这 直接导致了两者的应用有很大的差别。 总的来说,这段时间的 RTC 应用摆脱了早期单调的文本实时通讯,开始针对不同 的用户群体开发了丰富多彩的应用,使 RTC 用户数仍然保持很高的增长速度。 3、产品创新期的 RTC(2004 年以后) 2004 年之后,各个厂商对 RTC 用户的争夺更加激烈,同时互联网上的新应用发 展速度更加快,很多功能非常具有创新性,并且这种创新性的应用传播速度非常 之快,远远超出了传统工业中新技术的扩散速度。这些应用当中比较具有代表性 的有博客(Web Blogger:也称为网络日志)、RSS(Really SRTCple Sydicattion)、 音乐文件共享、视频点播(VOD:Video On Demand)等,为了保持用户对 RTC 软件的黏性,各个厂家都想尽办法将这些新技术部署到新版本的 RTC 产品中去。 同时,由于用户增长速度已经开始下降,社会上要求现有 RTC 运营商之间实现互 联互通的呼声越来越高,在产品应用期阶段中开始讨论的标准统一问题的解决进 度大大加快,互联网上主要的标准制订组织 IETF(Internet Engineering Task Force)对 RTC 行业技术标准的讨论进入了实质性阶段。部分厂商之间的 RTC 产 品已经开始了互通的尝试,这使得原来依靠封闭协议来保持用户忠诚度的 RTC
厂商开始转变策略,目前已经肯定不同 RTC 产品之间的互联互通是未来的发展方 向,但具体到每个厂商,其进度和实施策略却由于商业利益而有很大的差异,互 通性本身实际上已经成为 RTC 产品的一个创新性。 本阶段的另一个重点创新是 RTC 技术开始进入企业内部网(Intranet),或者称 为企业级 RTC,如腾讯公司的 RTX、微软公司的 LCS、AOL 的 Enterprise ARTC 等,这直接导致了 RTC 的应用向企业级软件层次发展。另一个重要的发展是人们 对 RTC 产品的安全性开始重视起来,特别是 2004 年几次大的计算机病毒流行都 是通过 QQ、MSN Messenger 等 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.1 Winsock 通信原理 2.1.1 TCP 和 UDP 1、TCP 报文段格式 两台机器之间的 TCP 传输的数据单元叫报文段(segment)。TCP 通过报文段的 交互来建立连接、传输数据、发出确认、通告窗口大小以及关闭连接[2]。 TCP 每个报文段分为两个部分:首部和数据。首部携带了所需的表示和控制信息 源。端口(SOURCE PORT)和目的端口(DESTINATION PORT)字段包含了连接两 端对应应用程序进行标识的 TCP 协议端口号。序号(SEQUENCE NUMBER)字段指 出了这个报文段在发送方的数据字节流的位置。确认号(ACKNOWLEDGEMENT NUMBER)字段指出了本机希望接受的下一个八位组的序号。 2、UDP 协议的报文格式 在 TCP/IP 协议族中,用户数据报协议 UDP(User Datagram Protocol)是传输 层上另一个重要的协议[3]。它为应用程序之间提供面向无连接的不可靠的数据 报的传输服务。UDP 使用底层的 Internet 协议,在各机器之间传输报文,提供 和 IP 一样的不可靠的、无连接数据报交付服务。它是一个非常简单的协议没有 使用确认机制来确保报文到达,没有对传入的报文重新排序的功能,也不提供反 馈信息来控制机器之间信息流动的速度。所以 UDP 的报文传输可能出线丢失、重 复、延迟以及乱序的错误。
源端口(SOURCE PORT)字段和目的端口(DESTINATION PORT)字段包含了 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/Server model)。该模式的建立基于以下两点[5]:1、非对等作用;2、
通信完全是异步的。客户机/服务器模式在操作过程中采取的是主动请示方式: 首先服务器方要先启动,并根据请示提供相应服务:(过程如下) (1)打开一通信通道并告知本地主机,它愿意在某一个公认地址上接收客户请 求。 (2)等待客户请求到达该端口。 (3)接收到重复服务请求,处理该请求并发送应答信号。 (4)返回第二步,等待另一客户请求 (5)关闭服务器。 客户方: (1)打开一通信通道,并连接到服务器所在主机的特定端口。 (2)向服务器发送服务请求报文,等待并接收应答;继续提出请求…… (3)请求结束后关闭通信通道并终止。 2.1.3 Winsock API 主要函数简介 1、创建套接字–socket() 功能:使用前创建一个新的套接字 格式:SOCKET PASCAL FAR socket(int af,int type,int procotol); 参数:af: 通信发生的区域 type: 要建立的套接字类型 procotol: 使用的特定协议 2、指定本地地址–bind() 功能:将套接字地址与所创建的套接字号联系起来。 格式:int PASCAL FAR bind(SOCKET s,const struct sockaddr FAR * name,int namelen); 参数:s: 是由 socket()调用返回的并且未作连接的套接字描述符(套接字号)。 其它:没有错误,bind()返回 0,否则 SOCKET_ERROR 地址结构说明: struct sockaddr_in { short sin_family;//AF_INET u_short sin_port;//16 位端口号,网络字节顺序 struct in_addr sin_addr;//32 位 IP 地址,网络字节顺序 char sin_zero[8];//保留 } 3、建立套接字连接–connect()和 accept() 功能:共同完成连接工作 格式:int PASCAL FAR connect(SOCKET s,const struct sockaddr FAR * name,int namelen); SOCKET PASCAL FAR accept(SOCKET s,struct sockaddr FAR * name,int FAR * addrlen); 4、监听连接–listen() 功能:用于面向连接服务器,表明它愿意接收连接。 格式:int PASCAL FAR listen(SOCKET s, int backlog); 5、数据传输–send()与 recv() 功能:数据的发送与接收
分享到:
收藏