- im即时通信程序设计
- im即时通讯
- 设计一款高并发聊天服务需要注意什么
- 如何设计可靠的消息处理服务
- 什么是粘包
- 什么是半包
- 解决粘包和半包
- im通信协议
- 应用层协议设计
- 文本协议
- 二进制协议
- 流式xml协议
- 应用层协议设计
- 数据传输格式
- 聊天服务设计
- 消息处理
- 消息分发
- 用户注册
- 用户登陆
- 用户登出
- 群聊
- 私聊
- 添加好友
- 获取好友信息
- 获取群列表
- 获取群信息
- github源码
im即时通信程序设计
界面相对简陋，主要界面如下
- 登录界面
- 注册界面
- 聊天界面
- 添加好友界面
支持的功能
- 注册账号
- 登录账号
- 添加好友
- 群聊
- 私聊
后续ui美化以及功能增加持续更新，关注微信公众号「编程学习基地」最快咨询..
im即时通讯
本系列将带大家从零开始搭建一个轻量级的im服务端，麻雀虽小，五脏俱全，我们搭建的im服务端实现以下功能：
- 注册
- 登录
- 私聊
- 群聊
- 好友关系
第一版只实现了im即时通讯的基础功能，其他功能后续增加.
设计一款高并发聊天服务需要注意什么
- 实时性
在网络良好的状态下服务器能够及时处理用户消息
- 可靠性
服务端如何防止粘包，半包，保证数据完全接收，不丢数据，不重数据
- 一致性
保证发送方发送顺序与接收方展现顺序一致
实时性就不必细说了，保证服务器能够及时处理用户消息就行，重点说下可靠性
如何设计可靠的消息处理服务
简单来说就是客户端每次发送的数据长度不定，服务端需要保证能够解析每一个用户发送过来的消息。
这就涉及到粘包和半包，这里说下粘包和半包是什么情况
什么是粘包
多个数据包被连续存储于连续的缓存中，在对数据包进行读取时无法确定发生方的发送边界.
例如：客户端需要给服务端发送两条消息，发送数据如下
char msg[1024] = "hello world";
int nsend = write(sockfd, msg, strlen(msg));
nsend = write(sockfd, "粘包", strlen("粘包"));
服务端接收
char buff[1024];
read(connect_fd,buff,1024);
printf("recv msg:%s\n",buff);
结果就是服务端将两条消息当成一条消息全部存入buff中。输出如下
recv msg:hello world粘包
当客户端两条消息发的很快的时候，服务端无法判断消息边界导致照单全收的情况就是粘包。
什么是半包
单个数据包过大，服务端预定缓冲不够，导致对数据包接收不全
例如：客户端需要给服务端发送一条消息，发送数据如下
char msg[1024] = "hello world";
int nsend = write(sockfd, msg, 1024); //发送字节大小为1024
服务端接收
char buff[128];
read(connect_fd,buff,128);
printf("recv msg:%s\n",buff);
结果就是服务端缓冲不够，只能读取部分包内容。
解决粘包和半包
如何解决粘包和半包的问题？
通过自定义应用协议，客户端给数据包进行封包，服务端进行拆包。
以项目实例来说，定义包头 包 负载
其实就是发送数据包的时候先发一个包头，包头里面有一个字段表示包的大小
包头后紧跟着包，这个包还不是数据包，只是数据包的描述信息，例如发送消息代表一个命令，字段command用来从存储命令，让服务器能够解析这是群聊数据包还是私聊数据包。包头和包定义付下
struct demessagehead{
char mark[2]; // "de" 认证deroy的协议
char version;
char encoded; //0 不加密，1 加密
int length;
};
struct demessagepacket
{
int mode; //1 请求,2 应答,3 消息通知
int error; //0 成功,非0,对应的错误码
int sequence; //序列号
int command; //命令号
};
负载就是你真正要发送的数据包结构了，可能是msg消息，又或者其他的自定义消息。
im通信协议
所谓“协议”是双方共同遵守的规则.
协议有语法、语义、时序三要素：
（1）语法：即数据与控制信息的结构或格式
（2）语义：即需要发出何种控制信息，完成何种动作以及做出何种响应
（3）时序：即事件实现顺序的详细说明
一套典型的im通信协议设计分为三层：应用层、安全层、传输层。
应用层协议设计
在通信过程中，chat_room使用的是tcp作为传输层的协议，暂时未引入数据加密解密，所以未涉及安全层协议。
应用层协议选型，常见的有三种：文本协议、二进制协议、流式xml协议。
文本协议
文本协议是指 “贴近人类书面语言表达”的通讯传输协议，典型的协议是http协议。
一个http协议大致长成这样：
get / http/1.1
user-agent: curl
host: musicml.net
accept: */*
文本协议的特点是：
a. 可读性好，便于调试
b. 扩展性也好（通过key:value扩展）
c. 解析效率一般（一行一行读入，按照冒号分割，解析key和value）
d. 对二进制的支持不好 ，比如语音／视频
二进制协议
二进制协议是指binary协议，典型是ip协议。二进制协议一般定长包头和可扩展变长包体 ，每个字段固定了含义，此次项目设计chat_room采用的就是二进制协议作为应用层的传输协议。
二进制协议有这样一些特点：
a. 可读性差，难于调试
b. 扩展性不好 ，如果要扩展字段，旧版协议就不兼容了。
c. 解析效率超高
qq使用的就是二进制协议
流式xml协议
这个一般场景用的比较少了，我所接触的就是onvif协议交互用的就是流式xml协议。
xml协议特点：
a.它是准标准协议，可以跨域互通
b.xml的优点，可读性好，扩展性好
c.解析代价超高
d.有效数据传输率超低（大量的标签）
数据传输格式
即时通讯应用（包括im聊天应用、实时消息推送应用等）在选择数据传输格式的时候比较纠结，不过我个人建议将protobuf作为即时通讯应用的首选通讯协议格式。此次项目设计未使用protobuf是因为不想导入第三方库，怕有些同学直接劝退。
据说，手机qq的数据传输协议已在使用protobuf了，而从官方流出资料来看微信很早就在使用protobuf（而且为了尽可能地压缩流量，甚至对protobuf进行了极致优化）。
此次项目使用的是二进制数据流作为数据传输格式，其实就是一堆结构体变量。
例如登陆的数据包定义如下:
struct logininforeq{
int m_account;
char m_password[32];
};
服务端和客户端双方约定好一个数据结构就可以了，特点就是简单。
聊天服务设计
目前采用的是多线程处理客户端请求，即一个客户端一个线程，这周会改成io多路复用，用epoll来接受更高的并发。
整体设计如下:
第一步:客户端发送数据包
第二步:服务端解析数据包，传递给各个业务处理模块
第三步:业务处理模块按照通信协议解析并处理消息
消息处理
对客户端的消息处理就是接受一个完整的数据包，传递给服务器。
由于采用封包-拆包作为通信的传输协议，所以在处理数据包的时候需要一个健壮的数据处理逻辑
此次项目处理逻辑如下
int session::readevent()
{
int ret = 0;
switch (m_type)
{
case recv_head:
ret = recvhead();
break;
case recv_body:
ret = recvbody();
break;
default:
break;
}
if (ret == ret_again)
return readevent();
return ret;
}
先读取头，在读取到head包头之后申请body(包 负载)所需空间，再读取body,body读取完毕之后传给消息分发的逻辑。
消息分发
服务端是如何区分群聊消息和私聊消息？在我们解决粘包和半包问题的时候就给出了答案。
客户端封包结构为：包头 包 负载
在pack包里面有一个代表命令的字段 command.
struct demessagepacket
{
int mode; //1 请求,2 应答,3 消息通知
int error; //0 成功,非0,对应的错误码
int sequence; //序列号
int command; //命令号
};
服务端可客户端双方约定的 cmmand 如下
//命令枚举
enum{
commandenum_registe,
commandenum_login,
commandenum_logout,
commandenum_groupchat,
commandenum_addfriend,
commandenum_delfriend,
commandenum_privatechat,
commandenum_creategroup,
commandenum_getgrouplist,
commandenum_getgroupinfo,
commandenum_getfriendinfo,
};
服务端通过switch匹配各个命令，进而对每个命令进行处理。
用户注册
用户注册请求，响应的数据格式如下
/**
* @brief 注册用户信息
*/
struct registinforeq{
char m_username[32];
char m_password[32];
};
struct registinforesp{
int m_account;
};
在用户注册时，服务端生成一个唯一的账号发送给客户端，客户端只能通过该账号与服务端交互。
用户注册完成之后会存放在服务端的一个全局map表中,方便集中管理
typedef std::map<int,registinforeq*> mapaccountinfo; //注册用户表
static mapaccountinfo g_accountinfomap; //注册账户信息表
用户登陆
用户登陆请求，响应的数据格式如下
struct logininforeq{
int m_account; //账号
char m_password[32];
};
用户登陆成功后会创建一个用户信息 userinfo 并将该用户信息添加到全局的一个用户map表中集中管理
typedef std::map<int,userinfo*> mapuserinfo; //在线用户表
static mapuserinfo g_userinfomap; //在线用户信息表
登陆成功之后发回给客户端的是一个没有负载的包，包中的error字段置0.
用户登出
客户端直接断开即可，具体登出数据格式暂未实现.
群聊
此次设计中有一个公共群聊（账号为0），所有用户都在群聊里面。
用户群聊请求，响应的数据格式如下
truct groupchatreq
{
int m_useraccount; //发送的账号
int m_msglen;
int m_type; //数据类型 0:文本,1:图片 ...
int m_groupaccount; //发送群号 0:广播
};
看着没啥毛病但是群消息在哪？要发送的数据在哪？
还记得我们客户端封包结构：包头 包 负载
负载里面包含了 数据传输格式 其他数据
在群聊请求里面有一个 m_msglen字段用来区分消息的边界，因为客户端发送的消息是不定长的，所以需要这么一个字段来区分消息的边界。
私聊
用户私聊请求，响应的数据格式如下
struct privatechatreq
{
int m_useraccount; //发送的账号
int m_msglen;
int m_type; //数据类型 0:文本,1:图片 ...
int m_friendaccount; //发送好友账号
};
跟群聊类似，其实这两个数据格式可以用同一个。
添加好友
用户添加好友请求，响应的数据格式如下
struct addfriendinforeq
{
int m_friendaccount; //好友账号
int m_senderaccount; //发送端账号
char m_reqinfo[64]; //请求信息 例如我是xxx
};
struct addfriendinforesp
{
int m_friendaccount; //好友账号
int m_senderaccount; //发送端账号
int status; //同意0，不同意-1
};
添加好友的流畅比较复杂，我在设计的时候也卡了一下。
主要流程如图
- 客户端a给服务器发送添加好友的请求
addfriendinforeq,服务器解析请求将b的信息添加到客户端a的好友表中。 - 服务器b给客户端b转发好友请求。
- 客户端b同意或者拒绝，给服务器发送添加好友的响应
addfriendinforesp，服务器解析请求将a的信息添加到客户端b的好友表中，将客户端a的好友表中属于客户端b的好友状态字段m_status置1或0。
获取好友信息
用户获取好友信息请求，响应的数据格式如下
/* 好友请求接口封装 */
struct getfriendinforesp
{
int m_size; //群成员大小
};
struct friendinfo{
char m_username[32];//好友用户名
int m_account; //账号
int m_status; //是否添加成功 0:等待添加 1：同意
};
这里大伙可能有点蒙了，又是包头，又是包，又是负载的，拿着数据格式到底属于那块的
其实数据格式（例如getfriendinforesp结构体）和数据都属于负载里面的,如图所示。
对于通信协议为二进制的协议来说，解析起来效率是最快的。
获取群列表
用户获取群列表信息请求，响应的数据格式如下
struct getgrouplistresp
{
int m_size; //群数量大小
};
struct groupchatinfo
{
char m_groupname[32]; //群名称
int m_account; //群账号
int m_size; //群大小
};
数据的传输同获取好友信息，在这里群列表也有一个map表统一管理。
获取群信息
用户获取群信息请求，响应的数据格式如下
struct getgroupinforeq
{
int m_groupaccount; //群号 0:广播
};
struct getgroupinforesp
{
char m_groupname[32]; //群名称
int m_groupaccount; //群号 0:广播
int m_size; //群成员大小
};
struct groupuserinfo{
char m_username[32];
int m_account; //账号
int m_right; //权限 0:群成员 1:群管 2:群主
};
这里的数据传输和获取好友信息一样。
到这里尊龙凯时官网入口的服务端介绍完了，比较复杂，但是知识点超多。客户端设计相对容易些，但是我感觉单纯的终端客户端太掉逼格了，就又写个一个qt的客户端，重温了一边qt的ui设计，简直不要太爽，qt的客户端设计会另外再补一篇文章。
github源码
chat_room:https://github.com/aderoy/chat_room
欢迎慷慨 star
上一篇：
下一篇：
发表评论
还没有评论，快来说点什么吧~
