学海无涯苦作舟！
2.1.4 即时通讯
即时通讯模块用户可以与在线的好友进行聊天，用户首先查看好友是否在线，如果在线即可进行即时通讯，并且用户可以查看与好友的所有聊天记录。即时通讯如图2-4所示。
图2-4 即时通讯用例图
2.2 通讯模型的特点
2.2.1 适用性
作为一个一般性的模型，本通讯模型适用于无线网络和Internet上现存的多种系统。模型中的JQQ可以是Internet上的应用程序，也可以是移植到移动电话和其他各种无线手持设备上的应用程序。即时通讯和服务可以是Internet上ICQ服务，可以是GSM标准中的SMS(Short Message Service，短信息服务)，也可以是NTT Do Co Me的I-MODE服务。 2.2.2 扩展性
模型具有很强的扩展性。本模型并没有规定服务必须采用中央服务器。在模型实现的时候，可以使用基于中央服务器的星形结构，也可以使用对等网络结构甚至其他混合结构。例如，深圳腾讯QQ的通讯服务系统使用的是基于中央服务器的Client/Server的混合星型结构，而即时通讯服务使用的是对等网络加客户机——服务器结构。
2.3 可行性研究
2.3.1 技术可行性分析
（1）项目开发过程中遇到难以克服的技术问题，该怎么办。
这一方面，我们庆幸的是在学校我们有好多的老师在背后支持着我们，同时学校的网络比较方面，给我们解决问题提供了方便。而且，凭借借阅图书馆收藏图书更增加了
学海无涯苦作舟！
我们解决技术问题的信心。
（2）软件的质量如何。
有些应用对实时性要求很高，如果软件运行慢如蜗牛，即便功能完备也毫无实用价值。有些高风险的应用对软件的正确性与精确性要求极高，如果软件出了差错而造成用户利益损失，那么软件开发在某种意义上说也就失败了。
鉴于此，我们在编码测试的时候，找专业老师做为技术支持。并且在完成之后，实际验证可行性，同时要考虑到机器硬件设备的不同而给软件带来的不可预知的结果，所以在机房的不同电脑上运行软件达到测试目的。 2.3.2 不确定性分析
需要格外考虑的实际情况也可以说是面临的一个现实问题就是：毕业生面临着毕业与找工作，还有就是最后的毕业答辩与论文设计。这个过程中，学校会有许多有关毕业生的信息要安排，事物要处理。在进行课题设计的时候，难免会有一些格外的因素，如，时间被耽误，在规定的时间中无法完成相应的任务；有问题存在的时候，老师也恰巧也有事情，问题无法及时解决等一系列问题，都是要考虑在内的。
再有就是，最害怕在做系统的中途遇到系统崩溃而东西又无法保存；或者是东西全部做好之后，忘记了备份，而更为不巧的是以染上了病毒，而致使几个月的辛苦负于东流。这些是容易忽视的也是最容易出现的情况。所以要在设计的时候做足这方面的准备，不让那种情况发生。 2.3.3 分析结论
通过上面简要的分析，最后做出的结论是：方案可以按照时间要求、保证质量的基础上运用MyEclipse与SQL Server 2000 数据库进行系统的开发。
2.4 运行环境
操作系统：windows2000server中文版、windows 2003 Server或者Windows XP Sp3 数据库：SQL Server 2000 中文个人版 开发工具:MyEclipse 7.1
硬件配置：CPU 1.7GHz以上，内存512MB以上
3 概要设计
3.1 框架设计
本系统总体框架如图3-1所示。
学海无涯苦作舟！
图3-1 系统总体框架图
3.2 拓扑结构
系统的拓扑结构如图3-2所示。
C1 S3 C2 S1 C2 S1 C1 S3 S2 S2 C3 客户端—服务器星型结构 服务器—服务器对等结构
模式一
C 客户端
S 服务器
C3 客户端—服务器星型结构 服务器—服务器对等结构 客户端—客户机对等结构
模式二
客户端—服务器连接 服务器—服务器连接
客户端—客户端连接
图3-2 系统的拓扑结构图
学海无涯苦作舟！
现在不少即时通讯系统服务的内部拓扑中采用模式一；也有极其个别系统在即时通讯服务上面采用模式二(例如，深圳腾讯的QQ服务中的即时通讯服务，发信者首先考虑直接与即时收信箱进行通讯，如果发现直接通讯超时，会转为使用服务器中转完成通讯)。
模式一是一种非常成熟的模式，大多数TCP/IP应用系统，例如SMTP服务、DNS服务、WWW服务等都是使用这种模式。模式二，对于模式一是一个技术上的修正，虽然这个修正带来了新的问题，但是其实用性是不可质疑的；JQQ正是实用模式二作为服务模式。
JQQ的服务是由服务器构成的；JQQ中每个实体都由一个寄主服务器管理。个体必须向服务器注册，注册后就有可以控制的发信者和即时收件箱。发信者是独立于即时通讯服务外的实体，而即时收信箱则存在于寄主服务器中。JQQ的通讯系统中只有存在发送者和接收者两类实体。注册后的用户必须在服务器上建立登记表，才能知道其他用户的存在，与其他用户进行交流。 1) TCP协议
TCP和UDP是TCP/IP协议族的两个主要的传输协议，TCP是面向连接的，UDP是面向无连接的，而实际上他们最大的区别在于为应用协议提供不同的服务，TCP协议为应用程序提供点到点的通信：建立可靠的连接。如果有故障发生，阻碍分组到达远程系统，或者服务器不接受连接，客户都会得到通知：数据可靠的交付，故障而不能交付，发送方会得到通知；具有流控的传输；双工的传输，单个TCP连接允许同时双向传送数据流模式，TCP从发送方到接收方发送没有报文边界的字节。
2) UDP协议
UDP为应用程序提供多对多的通信，UDP在进行通讯的应用的数量上面，具有更大的灵活性。多个应用可以向一个接收方发送报文，一个发送方向也可以向多个接收方发送报文。UDP还可以使用底层网络的广播和组播设施交付报文：UDP提供的是不可靠交付语义，报文可能丢失、重复或者失序，而发送方是得不到通知的；缺乏流控制；报文模式，当有数据交付的时候，必须制定报文边界。
3) 传输层协议的选定
由于TCP和UDP的语义及其不同，如果要考虑应用协议所要求的语义，设计者就不能不在面向连接和无连接的传输协议间作出选择。利用面向连接的TCP协议，可以大大简化应用协议的设计工作。由于UDP不提供可靠的交付，无连接传输要求应用协议提供可靠性，并在必要时，使用一种称为自适应重传的复杂技术。为现有的应用程序增加自适应重传比较困难，它需要程序员具有相当地专业知识。
选择TCP一个很大的缺点就是，建立和中止连接的三次握手使TCP比起UDP开销大。在考虑是用UDP还是用TCP作为域名服务系统的运输层协议是，设计者往往陷入两难的
相关推荐：
loading