没有合适的资源?快使用搜索试试~ 我知道了~
基于UDP协议的点对点聊天程序设计报告.docx
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 101 浏览量
2022-11-24
14:03:37
上传
评论 1
收藏 361KB DOCX 举报
温馨提示
试读
23页
...
资源推荐
资源详情
资源评论
目 录
一、需求分析 ................................................................................ - 1 -
二、概要设计 .....................................................错误!未定义书签。
三、详细设计 .....................................................错误!未定义书签。
四、设计和调试分析 .........................................错误!未定义书签。
五、用户手册 .....................................................错误!未定义书签。
六、测试结果 .....................................................错误!未定义书签。
七、参考文献 .....................................................错误!未定义书签。
一 需求分析
理解基于 UDP 的网络编程技术,分析点到点聊天程序设计原理和程序流
程,选择合适的开发环境,参考已有的点到点聊天程序功能,设计实现点到
点聊天功能的应用程序。
1.UDP 协议的理解:
UDP 协议是英文 UserDatagramProtocol 的缩写,即用户数据报协议,主
要用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议
系统在内的众多的客户/服务器模式的网络应用都需要使用 UDP 协议。UDP
协议从问世至今已经被使用了很多年,虽然其最初的光彩已经被一些类似协
议所掩盖,但是即使是在今天,UDP 仍然不失为一项非常实用和可行的网络
传输层协议。UDP 协议直接位于 IP(网际协议)协议的顶层。UDP 协议的主
要作用是将网络数据流量压缩成数据报的形式。一个典型的数据报就是一个
二进制数据的传输单位。每一个数据报的前 8 个字节用来包含报头信息,剩
余字节则用来包含具体的传输数据。UDP 协议使用端口号为不同的应用保留
其各自的数据传输通道。正是采用这一机制实现对同一时刻内多项应用同时
发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将 UDP
数据报通过源端口发送出去,而数据接收一方则通过目标端口接收数据。有
的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用
则可以使用未被注册的动态端口。因为 UDP 报头使用两个字节存放端口号,
所以端口号的有效范围是从 0 到 65535。一般来说,大于 49151 的端口号都
代表动态端口。数据报的长度是指包括报头和数据部分在内的总的字节数。
因为报头的长度是固定的,所以该域主要被用来计算可变长度的数据部分
(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理
论上说,包含报头在内的数据报的最大长度为 65535 字节。不过,一些实际
应用往往会限制数据报的大小,有时会降低到 8192 字节。UDP 协议使用报头
中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计
算得出,在传递到接收方之后,还需要再重新计算。如果某个数据报在传输
过程中被第三方篡改或者由于线路噪音等原因受到损坏,发送和接收方的校
验计算值将不会相符,由此 UDP 协议可以检测是否出错。UDP 协议并不提供
数据传送的保证机制。如果在从发送方到接收方的传递过程中出现数据报的
- 1 -
丢失,协议本身并不能做出任何检测或提示,由于排除了信息可靠传递机制,
将安全和排序等功能移交给上层应用来完成,极大降低了执行时间,使速度
得到了保证。
2.点对点设计原理分析:
在 C/S 模式中,数据的分发采用专门的服务器,多个客户端都从此服务
器获取数据。这种模式的优点是:数据的一致性容易控制,系统也容易管理。
但是此种模式的缺点是:因为服务器的个数只有一个 (即便有多个也非常有
限),系统容易出现单一失效点;单一服务器面对众多的客户端,由于 CPU
能力、内存大小、网络带宽的限制,可同时服务的客户端非常有限,可扩展
性差。P2P 技术正是为了解决这些问题而提出来的一种对等网络结构。在 P2P
网络中,每个节点既可以从其他节点得到服务,也可以向其他节点提供服务。
这样,庞大的终端资源被利用起来,一举解决了 C/S 模式中的两个弊端。
3.套接字编程原理分析:
注释 :socket() ,使 用前 创建 一个 新的 套接字 ;bind() ,将套 接
字 地 址 与 所 创 建 的 套 接 字 号 联 系 起 来 ; send() 与 recv() , 数 据 的 发
送与 接收 ;closesocket() ,关闭 套接 字 。
- 2 -
二 概要设计
服务器
客户机甲
客户机乙
客户机丙
整体框架设计如上图。
各个客户机发送信息前程序为其设置默认通讯端口,最大报文长度等参
数,再由用户指定接收端的 IP(单机或者是整个局域网),客户端创建监听
者,客户机向服务器发出信息时,监听者将监听信息发送状态,发送成功后,
服务器将根据数据报报头再发送给相应的客户机,同时监听者将监听是否有
信息发送到该客户机,以及接收是否成功,分析接收到的内容,是否有误,
是否为对方离线消息。
服务器端先初始化端口、最大报文大小,获取本机地址,初始化 winsock
环境,创建 socket 对象,将套接字绑定到本地地址,分配接收缓冲区,然
后创建监听者,监听者将监听是否有信息传入,并且监听是否接收成功,分
析接收到的信息,是否有误,是否为发送端离线消息。若收到的消息无误且
不是发送端的离线消息,则根据报头发送给相应的客户机,监听者将继续监
听消息是否发送成功。
- 3 -
三 详细设计
客户端:
初始化端口,最大报文大小,定义缓冲等参数
初始化 wsock 库,创建 socket 对象 s
输入接收端 IP 地址szRecipient
recipient.sin_addr.s_addr=本机 IP 地址前三位.255
ELSE SzRecipientrecipient.sin_addr.s_addr
用户输入消息szMessage
监听消息发送时是否产生错误
是否发送成功
分析收到的消息的内容,是否为对方离线消息
打印接收到的消息内容
- 4 -
剩余22页未读,继续阅读
资源评论
不吃鸳鸯锅
- 粉丝: 8300
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功