群聊系统项目（基于TCP、UDP实现）

最近学习了网络编程后，写了一个基于TCP、UDP协议的群聊系统。

技术栈

1、TCP、UDP通信
      2、生产、消费模型，支持并发
      3、自定义协议封装数据 & json封装数据
      4、STL中无序map、vector容器使用
      5、日志管理模块 - 在线显示后台情况
      6、ncurses库绘制聊天界面

支持功能

1、支持用户注册、登录。注册成功后台会返回一个账号ID，然后用户通过账号和密码进行登录，进入聊天系统进行聊天。
2、支持群发功能。当一方发送一次消息，其他在线用户都可以接收到。
3、支持在线用户显示。当用户发送一次消息后，其他用户的在线列表就会显示该用户。

原理剖析

一、注册、登录模块

1、注册、登录模块采用TCP协议实现。因为注册、登录模块的通信非常重要，因此采用TCP协议是为了保证的数据传输的可靠性。但由于是TCP，存在粘包问题，我们采用自定义协议（自定义实现的类）来解决粘包问题。

1、自定义注册信息协议

//注册信息
struct RegInfo{
       char NickName[15]; //用户注册的姓名
       char School[20]; //学校
       char Passwd[20]; //密码
};

我们可以看出这是一个普通的类，客户端在发送数据的时候按照RegInfo类的大小填充，服务器端接收数据按照RegInfo类大小接收并解析。这样就解决了粘包问题。（当然这样也有局限性，在于我们发送和接收数据大小是有限的)。在设计的时候，对于注册用户的个人信息和密码很重要。

2、自定义登录协议

//登录信息
       struct LoginInfo{
       uint32_t UserId; //返回用户使用的用户名
       char Passwd[20]; //密码
};

同样解决粘包问题，用户登录时用户ID 和密码非常关键。后台需要识别用户ID是否存在且存在是否密码正确的问题等

3、自定义应答

//应答信息
struct ReplyInfo{
int Status;
uint32_t UserId;
};

这个协议主要时服务器给我们客户端返回的数据包信息。同样解决粘包问题。
这个是客户端在发送注册数据包或者登录数据包后，它需要知道服务器处理的结果如何? 是否注册成功、注册失败，登录成功，登录失败等现象，并进行下一步的决策。

以上是为了解决TCP粘包问题并且为了解决双方协商的问题。
下面我们重点说注册、登录的细节流程。

1、客户端发送注册、登录数据包时，它先会发现1字节大小的数据包。它的目的为了让服务器端知道客户端是想注册还是登录。（服务器端后台会根据1字节进行选择，是用户注册协议接收下一个数据包还是登录协议接收）

#define REGISTER 0 //用户注册标识
#define LOGIN 1 //用户登录标识

如果1字节数据包发送的是0，服务器端会进入注册处理。
如果为1，服务器端会进入登录处理。

2、客户端发送注册请求。

3、客户端发送登录请求

二、用户管理模块

用户管理模块的功能：
1、当用户注册时，存储用户的个人信息，返回用户一个新的ID。
2、登录时判断该用户是否为合格。
3、进行聊天界面还需要判断黑户进入

我设计的用户管理模块包含的功能:1、用户注册；2、用户登录； 3、判断用户是否为黑户等接口。

其中userinfo是一个用户的类，包含用户的个人信息， ID，密码，用户的地址信息，用户的状态信息。

后台采用了unordered_map容器以<ID, userInfo>为键值对构建存储用户信息,
保证可以通过ID键可以查找，修改到对应的userinfo信息。

当用户注册完毕后，会在unordered_map中添加一个信息，并且将对应的userinfo类中的status置为已注册状态。

用户登录完毕后，会将对应的unordered_map中对应的userinfo类中status置为已登录状态。

为什么要这样做呢？
答：标志这些状态非常关键，我在后续会为大家演示，我在这里大体说一下功能。
防止黑户进入聊天界面。（按照正常的逻辑来讲，只有已登录的用户才可以进入聊天界面，然后聊天界面是UDP通信，如果别人知道我服务器的IP地址和UDP绑定的PORT端口，那是不是可以跨过注册、登录模块，直接进入聊天模块呢？？）

（聊天模块）当用户在聊天界面第一次消息后，我们会先检查该用户信息，然后判断该用户的状态status是否为已登录的状态，如果是，我们会在userinfo类中填充用户当前的地址信息，然后把用户的状态status置为已在线状态，并且将该用户userinfo添加到在线用户列表onlinelist中。（是一个vector<userinfo容器，它专门存储当前在线用户，功能在于转发所有在线用户，形成群发的特点。后续介绍）
如果用户不止一次发送过消息，二次或多次给我们发送消息时，我们会先检查，然后判断用户userinfo的状态为已在线状态。就不用管了。这种用户也是合格的。

三、生产、消费模型

生产线程 + 消费线程 + 线程安全的队列。
（实现需要互斥锁 + 条件变量 + STL中queue）

生产、消费模型的处理逻辑：

一开始线程安全队列为空，生产线程和消费线程一开始都会创建，由于一开始队列为空，因此消费线程会处于阻塞当中，当生产线程把需要处理的数据添加到线程安全队列中后，会唤醒消费线程去取数据处理。当消费线程处理完毕之后会唤醒生产线程去添加数据。这样形成一种良性的循环。对于队列的操作需要保证同步和互斥。

这是线程安全处理的方式之一。它的优点可以解决多线程带来的高并发问题。
（高并发：一个处理器处理，当存在大量的线程就绪准备使用CPU时，这种的情况就是高并发，高并发存在的问题线程切换，线程过多，频繁的切换，切换的时候会加载相应的信息，最终使得整个业务的处理缓慢）
生产、消费模型当队列满了时候生产线程会阻塞（阻塞的线程不会竞争CPU，它会在阻塞的队列中，等待唤醒），消费线程也同理。可以有效解决并发问题。

这种模型在CS模型中经常使用。

在这个项目中同样也是用到了它，我们生产线程负责把用户发来的数据添加到线程安全队列中，去唤醒消费线程去完成对所有在线用户的转发，从而形成群发的效果。

这个时候我们会用到上述的用户管理模块的用户在线列表vector<userinfo。
它里面保存的时在线的用户userinfo类。

这个时候只需要循环调用sendto接口发送即可，即实现群发。

四、聊天模块

服务器端：聊天模块就是UDP通信 + 生产消费模型

当客户端的聊天模块UDPsocket收到了数据包，这时候会收到json格式的string对象recv_string，我们需要进行json反序列化将用户发送的数据内容解析出来。

取出来的ID用来用户管理模块的用户检查（已在上面解释过）。

如果检查用户ID不合格，我们会忽略处理这条消息。

如果合适我们会将处理，将json格式的 recv_string 对象添加到生产、消费模型中的线程安全队列，从而唤醒消费线程去处理。（已在上面解释过）

客户端：当用户登录成功之后会进入聊天界面，聊天界面分为3块，接收消息区；发送消息区；显示在线用户列表区；当然还有顶部的介绍区（虽然有点尴尬！）

我们聊天模块采用UDP通信， UDP通信的好处：数据报传输，速度快。

对于发送的数据我们采用 json 封装和对应的解析。
需要json封装的数据有{ 用户的姓名； ID；发送的内容 }
（用户的姓名在后续的在线列表显示有用， ID用于检查用户，发送内容，聊天嘛，不能不说啥吧）

当用户收到服务器端的数据包时，它也是接收的json格式的数据。
对其解析后会到发送用户的姓名；发送用户的消息内容。
将发送用户的姓名在在线用户显示区显示。
将发送用户的数据在接收消息区显示。

从而在客户端会形成聊天的简单样子。但是核心就是这样实现的。

五、日志系统

在项目开发中，日志系统必不可少，我是第一次用到它，用过就说好。

它会标志我们服务器后台每一次的操作流程。
如果有问题可以查看日志系统进行分析，准备定位到错误。尤其是在大型开发中。

通过日志系统我们看出我们程序执行到那块，执行的怎么样，那些操作没做等问题。

六、演示：

注册登录界面：

交互界面

后台日志显示

源码链接：