引言
在上一节中,我们的1.0聊天室已经初步具备了简单的聊天功能,作为一名C++学习者来说,也算是能从小白晋升为半步初学者了。为什么只是半步?因为我们还需要进一步锻炼自己分析问题和解决问题的能力。
现在我们思考一个问题,之前的聊天室1.0存在着什么问题?或者说,我们要以怎样的方式和角度去发现他的问题?这都是我们要去思考的。
聊天室1.1雏形
我们要如何入手去分析问题呢?首先可以从聊天室的过程看起:一方产生数据,数据传输另一方,另一方再接收数据;如果再从聊天室的内容看,传输的数据可以增加产生数据的时间等;最后从聊天室程序的编译来看,我们简单粗暴的采用了命令行的形式进行编译,但是在每一次修改文件后都要再输入很长串的命令重新编译,那可不可以使用更方便快捷的方法进行编译呢?因此我们从以下三个层面对它进行分析:
- 1 通信层面——即双方使用的语言和协议所携带的数据流大小。
- 2 内容层面——即聊天室1.0的功能内容怎么做到进一步改进。
- 3 编译层面——即如何进一步改进聊天室1.0所使用的编译方式。
1 通信层面
首先我们看一下通信部分。
目前客户端和服务器都采用C++语言进行编写,那如果有一个java版本的聊天客户端也想加入到聊天室怎么办呢?因为我们的协议采用的是c 结构体形式进行传输的,所以java客户端接收到我们服务器的协议是解析不了的。
其次,每一次聊天所发送的内容都是整个数组结构的大小,可能我需要发送’hello’五个字节的大小但是实际却发了一整个数组结构,导致有很多的信息都是无用的。
为了解决上述的两个问题,我们就会思考:有没有一种通用传输协议,而且协议数据包携带的额外信息小,并且可以被各式各样的语言所识别呢? —— 有,而且有很多,这里我们使用的是google protobuf。(对这部分感兴趣可以搜索protobuf thrift json等序列化工具,这里不多做赘述)

本文介绍了C++聊天室项目从1.0到1.1的改进,主要关注通信、内容和编译三个层面。在通信层面,通过引入protobuf解决跨语言通信和数据冗余问题;在内容层面,增加了时间戳显示;在编译层面,利用cmake简化编译流程。通过这些改进,项目更具通用性和易用性。
最低0.47元/天 解锁文章
5790





