基于linux操作系统的聊天软件的设计毕业设计说明书

基于linux操作系统的聊天软件的设计毕业设计说明书内容摘要：

为 client 端和 Server 端之间的通信。 所以采用 C/S模型 进行网络聊天 系统的设计 需要分别编写 client 端 和 Server 端 的 源代码 ， client 端 和 Server 端 之间相互通信的程序流程如实验图 13 所示。 图 13 Socket通信流程图 网络套接字（ socket）的概念 Socket 接口 是 TCP/IP 的 API，它提供了 相应的功能函数与 例程， 我们 可以使用 对应的函数与例程进行 TCP/IP 应用程序 的开发与维护。 使用 Socket 套接字 进行网络通信的 开发 过程如 下面的 步骤： (1) 建立一个 Socket 套接字 (2) 按 我们所需要的 要求配置 好 Socket 套接字 ，将 socket 连接到 远程 server 端或者是本机 server 端 或给 Socket 套接字 指定本地协议端口 号。 (3) 按要求通过 Socket 套接字 发送和接受 相应的 数据 与信息。 (4) 完成通信以后我们需要 关闭此 Socket 套接字并且释放相应的其他销耗系统的操作。 以上就是 通过 Socket 套接字来 实现点对点 信息 通信 的 4 个编程 的核心 要点。 系统的选择 方案一：红帽子系统即 Red Ha 系统 是目前销售量最高、安装最简便、最适合初学者的Linux 发行版，也是目前世界上最流行的 Linux 发行套件，它的市场营销、包装及服务做的相当不错，自行开发了 RPM 套件管理程序及 X 桌面环境 Gnome 的众多软件并将其源代码回馈给 Open Source munity。 也正是因为 Red Hat 的方便性，安装程序将系统的构架或软件安装方式全部做了包装，用户学到的都是 GUI 界面（图形用户界面）上输入一些设置值的粗浅知识，至于软件安装了那些文件、安装到哪个文件目录、系统作了哪些设置，使用者则一无所知，一旦真正遇到系统程序发生问题时，要解决问题也就比较困难。 方案二： Caldera OpenLinux 系统， Caldera 将 OpenLinux 这套系统定位为容易使用与设置的发行版，以集成使用环境与最终用户办公环境，容易安装使用与简便管理为系统目标，有望成为最流行的公司团体台式 Linux 操作系统，适合初学者使用，全部安装需要 1GB 的硬盘空间。 Caldera 有自行研发的图形界面的安装程序向导，安装过程可以玩俄罗斯方块，提供完整的 KDE 桌面环境，附赠功能强大的商业软件，如 StarOffice、图形界面的硬盘分割工具Partition Magic 等。 方案三： SuSE Linux 系统， SuSE 是欧洲最流行的 Linux 发行版，而且 SuSE 是软件国际化的先驱，让软件支持各国语系，贡献颇丰， SuSE 也是用 RPM 作为软件安装管理程序，不过 SuSE 并不适合新手使用，提供了非常多的工具软件，全部安装 需 的硬盘空间，安装过程也较为复杂。 通过以上三种方案的比较，考虑适用性，和可操作性，选择 Red hat Linux 操作系统。 开发工具的选择 方案一： vi 编辑器， vi 编辑器 是 Linux 上最基本的 文本编辑器 ， 它是以 字符 模式 为核心的。 由于 去除了 UI 界面，使 vi 编辑器 效率 提高了 很 多。 在 Linux 上也有 许多 UI 界面的 编辑器 ，但 VI在系统和 服务器管理 中的 相应的 功能是 UI编辑器 不可以达到的。 VI编辑器 在 Linux上的 重要性是与 Edit 在 DOS 上 的地位是 一样。 Vi 编辑器 可以执行 文字 输出、 文字 删除、 文字 查找、 文字 替换、 文件 块操作等众多文本操作，用户 也 可以根据自 身的 需要对其进行 相应的 定制 和二次开发 ，这是其他 编辑程序 所 不能达到的效果。 加上红帽子系统中自带的 gcc编译器 和 gdb 调试 工具，所以 Linux 系统目前最主流的开发工具。 方案二： 用 eclipse 加 CDT+GCC+GDB，虽然 eclipse 拥有 方便的 UI 界面 ， 配置开发环境有点 复杂 ,如果配置好了，开发的效率还是不错的。 和 在 windows 下开发 基本相似。 用eclipse+CDT 可以 自动生成 makefile 文件，比较适合偏爱图形界面的开发人员。 通过以上两种方案的比较，考虑适用性，和编程习惯，选择方案一。 多线程与多进程 点对点通信的实现知识 ,了解了 主机进程与服务器进程之间的连接 关系 ，建立连接 了一对一的 进程联系，即主机的一个进程 必须与 服务器的一个进程之间建立 相应的 连接。 而 对于每一个 client 端服务器都要建立一个相应的进程去实现和 client 端的通信。 对于线程的并发情况我们就要建立多个线程去出来。 由于服务端 接受信息 的行为 是被动的，当 服务端 没有信息可以接收时，该进程就 应该自动的 阻塞，发送任务也 应该 一起被阻塞。 不同 端口的 收发之间就存在 并发 情况 ， 这样我们就应该 应该 建立多个 不同的 进程 去分别完成信息的 收发。 这样，当 一个 client 端的请求 被阻塞时，不至于影响 其它的 client 端 的 正常工作。 关于多进程和多线程， 我觉得 最 核心 的一句话是 “进程是资源分配的最小单位，线程是CPU调度的最小单位 ”。 方案一 ：多进程， 数据共享 非常 复杂，需要用 IPC 处理 ；数据是分开 处理的 ，同步 比较简单 ；但是 内存 耗的 多，切换 相应的会比较 复杂， CPU 利用率低创建销毁、切换复杂，速度慢 ；编程简单，调试简单； 适应于多核、多机分布式；如果一台机器不够，扩展到多台机器比较简单。 方案二：多线程，他的优点在于 共享进程 间的 数据，数据共享 就变的十分的 简单， 并且创建销毁、切换简单，速度很快 ，缺点也由于 这个原因导致同步复杂 ；虽然 占用内存少，切换简单， 但是 CPU 利用率高 ， 编程复杂，调试复杂 ； 一个线程 死掉 将导致整个进程 失去功能。 通过以上两种方案的比较，考虑适用性，选择多线程实现对客户端的监听。 I/O 多路复用 除了可以采用多进程和多线程方法去实现并发情况之外，还可以采用 I/O 多路复用这门技术来实现。 通过该技术，系统内核首先会缓冲 I/O 数据，当某个 I/O 准备好后，系统自动通知相应的应用程序去完成 I/O读或写操作，这样应用程序可以迅速的完成对应的 I/O操作，因而系统不需要等待完成相应 I/O 操作，从而应用程序设置阻塞。 因此我在收发信息方面使用了 I/O 多路复用去处理，即在处理群聊私聊的信息传送时。 对于 client 端，一旦我们输 入了一行文字发，系统会自动的读取，进而发送给系统内的server 端，然后由 server 端反馈给对应的目标 client 端。 方案一：当我们使用的 poll 函数 返回时，会 返回 一个文件是读写标志，应用程序根据不同的 返回 标志 去 读写相应的文件，实现 不用阻塞就可以完成 读写。 这 允许进程来决定 那个client 端 是可读或写一个或多个文件而不 用 阻塞 的。 poll 返回不同的标志， 这些标志 告诉主进程文件是否可以读写，其原型（定义在 linux\ ） : unsigned int (*poll) (struct file *filp, poll_table *wait)。 实现这个设备 的 方法分 为下面的 两步 : 1. 在一个或多个可指示查询状态变化的等待队列上调用 poll_wait. 当 文件描述符 不可以 可用来执行 I/O 时 , 内核 将使 这个进程在 处于等待状态，一旦又来可使用的文件描述符时， . 驱动 自动的 通过调用函数 poll_wait 增加一个 新的 等待队列到 poll_table 结构，原型 : void poll_wait (struct file *, wait_queue_head_t *, poll_table *)。 2. 返 回一个位掩码： 我们在处理某一些功能时 不必 要 阻塞 ，需要 立刻进行的操作， 那么我们就需要下面的 几个标志 (通过 linux/ 定义 )用来指示可能的操作 ，如表 21 所示： 标志 含义 POLLIN 如果设备无阻塞的读，就返回该值 POLLRDNORM 通常的数据已经准备好，可以读了，就返回该值。 通常的做法是会返回（ POLLLIN|POLLRDNORA） POLLRDBAND 如果可 以从设备读出带外数据，就返回该值，它只可在 linux 内 核的某些网络代码中使用，通常不用在设备驱动程序 中 POLLPRI 如果可 以无阻塞的读取高优先级（带外）数据，就返回该值，返回该值会导致 select 报告文件发生异常，以为 select 八带外数据当作异常处理 POLLHUP 当读设 备的进程到达文件尾时，驱动程序必须返回该值，依照 select 的功能描述，调用 select 的进程被告知进程时可读的。 POLLERR 如果设 备发生错误，就返回该值。 POLLOUT 如果设备可以无阻塞地些，就返回该值 POLLWRNORM 设备已经准备好，可以写了，就返回该值。 通常地做法是（ POLLOUT|POLLNORM） POLLWRBAND 于 POLLRDBAND 类似 表 21 poll函数返回的位掩码及其含义 方案二： select 函数： select()函数的接口主要 以 39。 fd_set39。 类型 为 基础 而建立的。 39。 fd_set)是一组文件描述符 (fd)的 大 集合。 由于 在不同的平台上 fd_set 类型的长度 是 不同 的 ，因此 规定用一组标准的宏定义来处理此类变量 显得尤其重要 ： fd_set set。 FD_ZERO(amp。 set)。 FD_SET(fd, amp。 set)。 FD_CLR(fd, amp。 set)。 FD_ISSET(fd, amp。 set)。 在过去，一个 fd_set 通常是小于 32 个文件描述符 的 ，因为 fd_set 其实 仅仅使用 了一个int 的比特矢量来实现 它。 在大多数情况下系统的责任 之一包括 检查 fd_set 能包括任意值的文件描述符， 但是当我们知道我们的文件描述符的多少时 你应该检查 /修改宏 FD_SETSIZE的值。 这个值是 与 系统相关的，同时 我们也要 检查 Linux 系统中的 自带的 sel。