企划
还是打算启动这个企划，核心的目标就像前一篇说的，我想做一个游戏的网络rpc的库。相比传统的rpc框架，核心在于这个是给游戏用的。
思考
游戏用的rpc和互联网的主要差别在哪呢？
这几天我一直在思考这个问题，互联网的请求更多的是我发起、等待然后收到回调。同时互联网有大量的基础设施，在rpc的通信中有大量的扩散的请求。例如一个订单可能涉及到向多个微服务发起服务，最终汇聚成一个请求返回到客户端。
互联网的rpc更注重跨语言，快速实现需求，还要考虑多服务的均衡、容灾等等…
而游戏的网络框架其实分两个部分，拿平安京举例，大厅的部分跟互联网的rpc没有太多差别的；但是战斗跟大部分互联网的需求是不同的，战斗更注重的是快速地相应，对游戏战场的控制方式。
所以我做这个还是有意义的，例如互联网的rpc框架默认就是基于TCP的，附带大量微服务特性的。
期望的特性
- 基于C++20：目的是学习；
- 支持UDP、TCP和WebSocket等协议：目的适配更广泛的游戏场景；
- 提供网卡、网络到连接层面的封装：目的是对网络有更精确的掌控力；
- 提供基于Entity和属性的同步：简化游戏开发；
- 提供局域网探测的功能：同样是为了提供简化的联网能力；
环境和依赖
稍微研究了一下，最后还是决定使用CMake + Conan做依赖管理。
尽量用公版以及conan中拥有的库做开发，减少我的开发成本，以及未来可能的管理成本。
倒腾了一个晚上，终于把conan2和cmake的融合做好了。
由CMake构建的时候引入conan2的conan_provider.cmake，这个cmake提供自动从云端的conan find_package，解决依赖问题。
工程只需要包含CMake以及工程源码，CMake就能自动从公版拉相应的库下来。
以及工程命名：Walo，想着朗朗上口，又要含义简单，取自网络的中文谐音。
End。