KonsanNet 网络通信框架实现（第四章）— 库封装、分层、容器、内存池（第一阶段结束）

本文链接：https://blog.csdn.net/moonbamboo/article/details/80561469

框架源码地址

GitHub：https://github.com/KonsanAlide/KonsanNet

修改内容阐述

这两天有些时间，修改了部分代码，为四部分：服务端库封装、消息包处理的分层、队列容器、内存池。

服务端库封装、消息包处理的分层

为了以后使用方便，把服务端的会话验证消息处理功能、用户消息处理、数据包压缩和加密处理这三部分抽到外层来，关于数据包的包头、组包、加密、压缩、校验等过程的数据处理都放到更内层的类来实现，服务端放在在CXConnectionObject里面进行处理，客户端放在CXTcpClient类里面处理。

本次版本0.5把服务端封装成一个库，然后实现了一个服务端的测试Demo: CXCommunicationServerTest。在CXCommunicationServerTest里面实现自定义的会话消息处理类CXSessionLevelBase的派生类CXAdvancedSessionMessageProcessHandle，自定义的用户消息处理类CXUserMessageProcessBase的派生类CXFileMessageProcessHandle，和自定义的数据包加解密、压缩解压类CXDataParserImpl的派生类CXFastDataParserHandle。当然会话消息处理可以使用默认的，不用真的实现，数据处理类CXDataParserImpl也可以不用实现，就是不压缩数据也不加密数据。但是用户消息总的自己定义吧，大家用的时候在继承CXUserMessageProcessBase类，在自定的派生类里面实现自己的消息包处理就行。

为了大家使用起来更简单，我把数据包的处理过程分层隔离，在最底层的CXConnectionObject类和CXTcpClient里面对数据包进行头部数据填充、校验、执行数据加解密和压缩解压缩。发送数据时，在上层的类里面把用户消息数据Buffer和长度给到底层的发送接口即可。接收数据时CXUserMessageProcessBase里面接收到的就是已经解压解密后的用户消息，不包含包头部分，这样简单明了。

内存池

为了内存池更方便使用，我在CXMemoryCacheManager类里面实现了更简便的内存分配和释放的接口，不再需要用户直接使用CXMemoryCache对象来操作内存块，而且未来可以在CXMemoryCacheManager类统一实现内存池的负载均衡管理。

CXMemoryCacheManager里面我为了加快分配内存块的速度，用一个数组取代了原来的hashmap来保存CXMemoryCache对象指针数组，数组里面保存256* 2^n 字节大小的块的 CXMemoryCache对象指针数组的指针，目前内存池里面的数据块最大支持1MB，所以n最大是13。

队列容器

最近在测试高并发的过程中，发现在消息队列CXMessageQueue里面，原来为了省事所用的std::queue耗费的CPU时长不大理想，所以我用类似内存池的方式实现了一个CXQueue的类，来替换std::queue的功能，简单测试下来，CXQueue的10万次push和pop操作的性能是std::queue的4倍左右。不过这个类，还需要修改，目前是使用的内存不停增长的，不进行任何的释放，下来应该加入当低耗时释放内存块的处理。