即时通讯系统的设计与实现毕业论文Word下载.docx
《即时通讯系统的设计与实现毕业论文Word下载.docx》由会员分享,可在线阅读,更多相关《即时通讯系统的设计与实现毕业论文Word下载.docx(39页珍藏版)》请在冰豆网上搜索。
目前,已经有不少即时通信软件在社会公众中流行,像MSN,腾讯QQ,新浪UC等,都是国内人们所熟知的知名流行即时通信软件,其技术方面也都处于国际领先水平。
同时,由于即时通信软件的便利,其应用已经由最初的简单的聊天交友得到了巨大的拓展。
适应各种场合的各式即时通信软件也开始出现在软件市场上,这就包括了一些与企业管理相关的即时通信软件,一个具有企业自己特色的集信息管理和即时通信为一体的内部应用软件,能够使一个企业或者团队更像一个整体,同时也能够给企业的管理和信息交流带来极大的便利,在一定程度上提高工作效率.
同样的,对于软件设计与开发的行业来说,过去的那种仅适用于PC机上的应用程序的开发已经远远不能满足市场的多样化的需求,网络程序的广泛应用和广大需求使学习与掌握与网络相关的编程技术显得尤为重要。
本论文将结合一个具体的局域网即时通信系统的开发编写,以现有的各种技术,介绍讲解网络IM软件开发中的重要知识,并讨论其中关键环节的技术问题和各种解决方案和设计策略
2相关技术知识简介
1.2.1基于SOCKET的网络编程
SOCKET在英文中的意思是插座,在网络编程中,其实际意义可以理解为网络通信连接的插座,通常称之为套接字。
如果将网络连接的各终端类比为电话,则SOCKET即相当于电话线插座,为各终端提供或者创建与其他终端通信连接的桥梁或通道。
所有的终端都必须接通此“插座"
来完成与其他终端的连接或通信,否则,它将独立于网络之外。
由此可以知道知道,SOCKET是终端间建立连接的核心对象。
那么,对于一个SOCKET对象,它到底具备什么样的功能呢?
通常,用WINSOCK库来创建和使用SOCKET,运用WINSOCK库的基本API,就可以实现简单的数据输入和输出(即发送数据和接受数据)。
在创建一个SOCKET对象后,通过指定IP地址来确定该SOCKET与哪台机器发生交流,通过指定机器端口号(一般为1024以上)确定与该机器上哪个应用程序进行交流。
在确定了交流对象后,便可以使用SOCKET与对象机器上的应用程序进行数据的传输和信息的交流.在面向连接的网络通信中,还必须使用SOCKET进行连接的监听和创建,只有创建了稳定的连接后,才开始进行数据的传输。
由于交互方式的不同,SOCKET也分为两种,一种是无连接的数据报形式的,一种则是面向连接的流式套接字,这也是接下来两小节要阐述的内容。
2。
2UDP协议与TCP协议的简单介绍
UDP协议是一个简单的面向数据报的运输层协议:
进程的每个输出操作都正好产生一个UDP数据报,并组装成一份待发送的IP数据报。
这与面向流字符的协议不同,如TCP,应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。
UDP不提供可靠性:
它把应用程序传给IP层的数据发送出去,但是并不保证它们能到达目的地,其过程可以比做投递信件,它只关心信件确实投放到信箱,至于对方是否正确、按时收到信件,UDP并不关心.
尽管TCP和UDP都使用相同的网络层(IP),TCP却向应用层提供与UDP完全不同的服务。
TCP提供一种面向连接的、可靠的字节流服务。
面向连接意味着两个使用TCP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接。
这一过程与打电话很相似,先拨号振铃,等待对方摘机说“喂”,然后才说明是谁并与之开始对话.
2.3WINSOCK套接字API调用的简单流程
本论文所要讨论的即时通信系统则是通过WINSOCK库的应用来设计和实现基于TCP的C/S结构的网络即时通信程序。
这里,用图的方式简单的表示出对WINSOCK库提供的API函数调用过程。
面向连接的流方式调用过程如图1—1所示。
图1—1面向连接的流式通信过程
面向无连接的数据报方式的调用过程如图1—2所示
图1-2面向无连接的数据报过程
从图中可以看出,面向连接的流方式更能适应C/S结构系统的非对称结构的实现。
1.3论文的主要工作与章节安排
本论文旨在设计一个面向企业内部的功能实用、性能良好的即时通信系统,并对其中关键模块做详细的分析和实现的说明。
在系统的设计和实现中,要突出系统的模块化,各模块间相对独立,通过模块间的接口交互工作,使整个系统层次、模块清晰。
在数据传输方面,要注意数据的封装,使数据尽可能结构化,保持良好的一致性。
根据上述要求,论文中详细阐述了系统的设计方案和关键模块的的实现方法,主要工作如下:
(1)在确定系统结构后,根据系统相关需求妄称对系统功能的设计和分析,并对应系统功能做出用户信息数据的设计,详细说明数据库表项的设计。
(2)对CLIENT与SERVER端的通信协议做详细的设计,并对协议数据包的结构的定义做出详细的阐释。
(3)对系统中网络传输模块的设计做详细的说明,阐述网络传输模块在系统中的工作流程以及该模块的实现方案。
(4)结合系统整体结构,说明系统在功能实现上的逻辑处理过程(选择最主要的功能如登陆认证和聊天消息收发),并展示系统部分功能实现后的运行结果。
按照上述的工作内容叙述,本论文共分5章来分别阐述有关问题,各章节安排如下:
第一章介绍论文背景、项目的意义、项目相关技术知识以及论文主要工作。
第二章对系统结构的分析做简单的介绍,针对系统的定性对其功能做详细的设计和分析,并设计出与系统功能相关的数据信息内容。
第三章详细介绍C/S系统中CLIENT与SERVER端之间的通信协议,并说明在系统实现过程中,该数据包结构以及部分协议内容定义.
第四章设计并分析系统中的核心模块——网络传输管理模块,对模块中重点对象的设计做详细的说明,并介绍该模块的实现策略,以及其在系统中的工作流程。
第五章介绍系统整体的结构模型,包含系统中各个模块中的对象,说明系统实现关键功能即登陆认证、聊天消息收发等的逻辑处理流程。
并展示系统运行过程中的部分截图.
2系统的结构与功能设计
1系统结构的选择和设计
2.1。
1系统通讯模式的选择
在前面,已经分别介绍了基于UDP和TCP的两种即时通信系统的基本模式。
在两者相比之下,由于TCP协议能够很好的提供数据传输的可靠性,并在面向连接的环境下提供更丰富的网络通信服务.而且,在面向连接的环境下,更有利于对网络应用终端的实时管理,为使用客户提供更加便捷可靠的网络服务.所以,在网络通信模式上,倾向于基于TCP的面向连接的流式通讯模式。
2.1.2集中式与分布式系统概述
在目前的网络通信系统中,对于连接节点的管理有集中式和分布式两种管理模式。
对于集中式的管理模式,系统的数据存储和管理以及各功能在网络连接上的对应操作,都集中在网络管理节点上进行处理和实现,即由单一服务器来完成网络数据的集中管理.集中式网络管理模式最大的优点就是便于集中管理各端连接,易于实现,维护工作较为简单。
但是,由于管理信息全部集中汇总到管理节点上,这就使得在通信高峰期会造成信息流拥挤,这对管理节点处的机器处理效率有很高的要求。
另外,由于所有的信息管理都依靠于一台服务器,当管理节点发生故障时,整个网络系统都将停止工作。
分布式管理模式,则是将网络管理客户机与一组服务器进行交互作用,由多个服务终端来共同协作完成对网络信息的管理。
由于有多个服务端协同工作,集中式容易造成信息流拥挤、服务器负荷太大的问题可以得到很好的解决。
同时,在多服务器的环境下,服务端之间的分工设计可以由设计人员灵活设计,系统的可伸缩性,扩展性也较为良好。
一般来说,采用的较多的则是多层管理或者服务器集群等技术方式。
3系统的结构设计
本论文所要讨论的系统是一个供中小型企业内部使用的带有简单人事管理功能的局域网即时通信系统,由于要存储并管理用户相关信息的数据,同时要限制普通用户对数据信息的管理权限,比较合适的设计是采用C/S模式的系统架构,数据由数据库进行存储,由服务器对数据库进行直接操作,而客户端则通过对服务器发出请求得到相应的数据或者告知服务器对数据库进行何种操作。
为了确保数据正确可靠地传输,系统采用面向连接的TCP协议作为数据传输模式.
通过上一小节对集中式网络管理和分布式网络管理的简单介绍,已经对两种管理模式有了初步的了解,可以看出,在对于功能繁琐多样,客户终端数量庞大的系统,分布式系统能够很好的减轻单个服务器的负载,以提高服务器管理网络连接的效率,为用户提供稳定而流畅的网络服务。
而对于本系统,由于定性为面向中小型企业,且是基于局域网内部的小型即时通信服务系统,其同时连接的客户终端本身极其有限,另外,本系统的功能也是集中针对于用户信息的管理和简单的实时通信交流,在这样的情况下,选择分布式系统则显得有些大材小用,并可能会造成开发成本上的浪费,而选择集中式管理模式则更有利于集中管理和系统的简化,同时,单一服务器的结构也相对于多服务器的结构更容易进行维护工作。
综上所述,本论文要论述的系统系统将使用基于TCP的集中式管理的C/S结构模型.在这个结构中,所有的数据信息都将由一个服务器程序进行统一的管理,对数据信息内容的各种相关操作也只能由服务器程序直接进行完成。
客户端要获得数据信息或完成某操作,必须通过服务器的验证,正确建立连接后,向服务器发送请求,服务器则根据客户端的请求代劳完成对数据信息的相应操作并向客户端回馈数据信息.图2—1表示了系统大大体层次和结构模型。
图2—1基于TCP的集中式C/S系统结构
2.2系统功能设计
本系统的使用对象为中小型企业,拟订要完成的主要功能为实时聊天会话功能,以及与之伴随的用户信息管理,并包括网络即时通信的相关通行功能.在扩展方面还应当加入固定群组会话与临时会话组等功能,进阶功能还包括文件传输,语音、视频对话等高阶功能.
2.2.1系统网络连接功能设计
对于一个网络即时通信系统而言,由于本系统采用基于TCP的集中式C/S结构,必须具备一些与网络连接相关的通用功能,无论系统的最终用途是什么,这些功能都是必不可少的,其中包括:
(1)客户端登陆验证功能
此功能用于用户使用客户端于服务器建立稳定连接,成功登陆是用户使用系统的先行条件。
客户端在连接上服务器后最先要做的就是将用户输入的ID和密码发送给服务器,服务器将收到的ID和密码与数据库中内容进行对比,符合则通过验证继续维持该连接,否则将返回错误信息并断开此连接。
(2)心跳功能
客户端应该在一定时间间隔内向服务器发送心跳信息,以告知服务器该客户端连接的活动状态,以便于服务器管理客户连接,如果超过时间间隔,服务器未收到某连接上的客户端的心跳信息,则自动认为该客户端网络异常或已经掉线,断开与其之间的连接.
(3)客户登出
与登陆功能对应,客户可以主动断开与服务器之间的连接。
这里需要注意的是,直接关闭客户端并不一定能够保证连接安全断开,未断开连接直接关闭可能会造成网络异常。
2.2.2用户信息相关功能设计
由于在该系统中,包含着很多于用户相关的数据信息,这些信息存放在服务器数据库中,并且用户会经常对这些信息进行即时查看或者修改更新,所以,与此相关的功能也是本系统中必须具备的基本功能,主要分为以下几个功能:
(1)部门信息查看和管理
在当今很多分工管理的中小型企业中,一个部门就是一个整体,部门之间往往都有着明确的分工,部门人员配置、职能也都各不相同,系统提供用户这样的功能能够使用户更便捷管理和了解企业中各个部门。
(2)员工信息查看和管理
与部门信息相比,作为一个即时通信系统,用户信息的查看和管理自然是必不可少的,用户可以通过此功能来查看自己或他人的详细信息,对自己的信息也可以做任意修改,我相信,任何一个即时通信系统都不会缺少这个功能.
(3)人事调动管理功能
这个功能可以说是本系统相对于其他即时通信软件来说所特有的。
由于有了此功能的设计,本系统中规定所有用户的注册工作全部由具有人事管理权限的用户通过此功能加入,同时,除个人详细信息外,所有用户与客户企业相关的信息也全部由有一定权限的用户来通过此功能设定或者修改.这样一来,此功能的加入使得该系统更具有针对性、专业性,为客户企业提供一个完善的管理交流平台,与平时常见的个人聊天软件有着本质上的区别。
3传输交流相关功能设计
作为一款即时通信系统,正常的聊天交流功能当然是重中之重,在本系统中,此方面的功能基本上也都是传承了当今流行的即时通信软件的一些流行功能,简要介绍如下:
(1)文字消息传输功能
本功能是即时通信中最简单的传输功能,也是最主要最常用的功能之一。
同时,本系统中,此功能除了包含通常的个人聊天外,还包含临时会话即会议聊天,以及固定群组聊天信息,甚至邮件消息等。
传输的主要内容也都是文字、字符信息.这个功能也是开发第一阶段里所用功能中最先进行开发和使用的。
(2)表情功能
此功能是模仿当今社会上所流行的多种即时通信软件,在文字消息的基础上添加默认表情的功能,而且通过字符转义来完成,这样就可以直接在文本消息的传输的基础上同时做到表情的显示。
(3)文件传输功能
由于现在不少企业单位都开始用计算机做为必备的办公工具,各种各样的文件大多数都是以电子文档的形式存放在工作计算机里,此功能的加入无疑给使用客户提供了便捷的文件传阅途径。
在该功能的支持下,各个客户终端间可以向对方发送本地机器中的任何格式的文件。
为企业中电子文件的传阅省时省力,提高工作效率.
(4)高级功能即扩展功能
该部分主要包括了邮件收发,文件上传,以及多媒体实时传输(其中包括实时语音或视频聊天等)。
由于此功能对技术要求稍高,同时需要扩展服务器数据库容量,在中小型企业中需求也并不是那么明显,将作为第二期项目功能扩展进行实现,本论文中将不会提到这部分的设计和实现。
2.3数据信息及数据库设计
在该系统中,需要在服务器中存储的数据信息主要包括员工信息和部门信息两个方面,在员工信息方面,又包含个人信息和工作相关信息两个方面,其中,个人信息是用户可以在获得登陆帐号后自行修改的,而工作相关信息只能由具有人事管理权限的用户通过人事管理功能来进行修改。
下面将结合本系统的数据库设计,介绍系统中包含的主要用户信息数据。
图2-2系统数据库E-R关系图
上面图2—2所示即为系统中用户信息数据的E—R关系图,接下来将以此E—R图来进行数据表的设计,按照数据表来创建系统服务器数据库数据.以下便是针对上述E-R建立的数据表(表中属性名后带*表示该项为外键):
(1)员工信息表如表2—1所示
表2—1员工信息表
列名
数据类型
长度
主键
允许为空
中文别名
属性名
员工ID
s_id
Varchar
√
No
员工用户名
s_userName
姓名
s_name
生日
s_birth
Data
登陆密码
s_pass
签名
s_sign
简介
s_intr
加入时间
s_data
联系邮箱
s_email
手机号码
s_phoneNumber
性别
s_sex
int
员工状态
s_state
(2)权限查询表如表2-2所示
表2—2权限查询表
s_id*
权限
s_right
(3)部门信息表如表2-3所示
表2-3部门信息表
部门ID
d_id
名称
d_name
d_intr
上级部门ID
d_super*
(4)员工—部门关系表如表2—4所示
表2—4员工—部门关系表
d_id*
职位描述
sd_desc
(5)群组信息表如表2-5所示
表2-5群组信息表
群ID
g_id
g_name
g_intr
进入方式
g_state
(6)员工—群组关系表如表2-6所示
表2-6员工-群组关系表
g_id*
群内身份
sg_degree
2.4本章小结
在本章中,介绍了系统整体结构的大致模型,并结合系统所针对的用户做了功能上的分析.通过对当今较为流行的系统模型的比较,在结构上,采用了基于TCP协议的集中式C/S模式,并对其进行了较为详细的描述.同时,根据系统的使用用户以及需求,设计出了一与寻常的IM系统相比更具有特色具有针对性、专业化的功能。
在功能设计的同时,依据实现功能所需要的信息,构造了系统的数据库模型以及用户的数据库信息。
为整个系统的性质和功能做了整体的概括和描述.在接下来的章节中,将围绕如何实现这些系统功能进行系统的设计和实现方案的描述.
3IMClient与IMServer之间的通讯协议
3.1数据收发方式与数据结构的设计和定义
3.1.1数据收发方式的设计
在IM中,所有功能的实现必须依靠客户端与服务端之间的数据通信来完成.在此,需要定义一个协议,让客户端与服务端之间按照定义的协议来进行数据通信,而不是杂乱无章的任意的数据收发。
首先,按照一般惯例,将要发送的数据做成数据包的形式来进行传输,并且分为请求包和应答包.所有的操作都首先由客户终端发送请求包给server端,server对终端的请求进行相应的处理(可能访问数据库)后将结果作为应答包的一部分返回给客户终端,终端通过解析应答包来得到IMserver的回应并继续执行相应操作。
在进行通讯及运行任何其他的command之前需要进行连接认证。
所有的操作都有“请求——应答”的模式来进行,其过程如图3—1所示。
图3—1请求应答顺序图
3.1。
2通信协议数据包结构定义
由于需要进行传输的数据以及客户端与服务端之间的通信数据的类型是多样化的,必须将种类繁多的数据,以尽可能相同或者相似的结构进行封装,否则,多样化的信息交互和数据传输将给实现功能和代码的编写带来巨大的麻烦和极其烦琐复杂的工作。
同时,数据的多样化使得各个数据包的长度将不相一致,甚至某些数据包的长度大小将是动态可变的,而在SOCKET网络编程中,每一次数据的接收和发送都是需要确定长度的。
为此,设计出这样一种方案:
将端与端之间一次要发送的数据包分离为两个部分,称为包头和包体,包头中包含有该数据包的相关属性信息,由于只是包含数据包属性而非真正的数据,所以,包头的长度可以是固定不变的。
而包体中,则是真正传输的数据所在,数据接收方根据包头中提供的信息得知包体中数据内容的类型,从而针对不同类型的包体做相应的接收和解析工作。
图3—2表示出了数据包的大致结构特征。
图3—2C/S通信协议数据包结构示意图
3。
2通信协议数据包在实现过程中的定义
2.1数据包包头定义
如图3-2所示,数据包的包头如同人的大脑一般重要,其中包含着该数据包所有的相关属性,能否正确接收变长的包体,解读包中的数据,将其转化为有用的信息,都取决于包体内容的正确解析。
在此,将请求包和应答包的包头统一起来,设计出一个一致可行的结构,其实现代码如下:
typedefstructdata_packet
{
charm_nMajorType;
charm_strServiceCode;
charm_strOperationCode;
charm_nReturnCode;
int32m_nUseless;
int32m_nSendID;
int32m_nRecvID;
int32m_nPacketLength;
}
其中,每个字段的说明如下表,表后有请求包和返回包的具体说明,如表3-1所示。
表3—1字段说明表
长度(byte)
说明
m_MajorType
1
区分IM和Mail的消息
IM:
0x01
Mail:
0x02
为二期开发邮件功能所留
m_strServiceCode
服务名
m_strOperationCode
命令名,具体定义见
m_nReturnCode
返回值
m_nUseless
4
协议扩展
m_nSendID
发送者的ID
下面的是特殊ID
0服务器
m_nRecvID
接收者ID,
m_nPacketLength
包体数据长度
总长
20
每个终端请求包中:
m_MajorType字段用来区分不同的服务类型,现阶段只使用0x01作为IM的类型,将来可能会增加0x02作为:
PushMail的类型。
m_strServiceCode用于区分不同的服务,如认证服务,命令服务等。
m_strOperationCode用于区分同一服务类型中不同的操作,如认证服务中包括登陆请求,断开连接两个操作.设计服务和操作有助于今后的扩展。
m_nReturnCode由应答包使用,请求包将不使用。
m_nPacketLength表示数据包体的长度,以便收取方缺定整个包的长度.
每个服务器应答包中:
m_MajorType,m_nFunctionCode,m_nSourceCode,以及m_strOperationCo