按照维基百科的说法。AEAD的全称是Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE)。也就是带附加数据的加密和验证算法。
我们很多涉及IO的系统收发数据的时候一般会加上一些校验码，以便检测IO错误。而对外的socket里，这个校验码还有一个功能是挡掉一些不正常的数据。如果这时候如果我们的数据需要带上加密的话，那就是AE了。然后AEAD就是在AE的基础上，增加一些自定义数据，用于防止猜解。
年前就计划把以前项目的一些理念和设计方案融合到sample里来。但是内容比较多，一直也没太多时间去完成它。所幸虽然断断续续但终归是完成了。并且在之前的一些实现上还做了一些细节的优化。内容比较多我感觉我自己写的也比较乱，仅当作一个参照和小计吧。
libcopp很早就实现完成了v2版本，现在迁移进atsf4g-co/tree/sample_solution以后也把v2分支正式并入了主干。原来的版本切出到v1分支并且停止维护了。
开发libcopp v2版本的最大目的是优化allocator的接口和内存碎片。
原来的allocator虽然是可定制的，但是是内置的。每次创建一个allocator对象，不同allocator之间共享数据只能通过全局数据或者TLS数据。现在则可以传入allocator了。这也是为后续的共享栈池做准备。
最近看Rust相关东西的时候看到一篇关于压缩可执行文件的文章。压缩可执行文件对嵌入式开发特别有用，但是延伸一下用来减少我们游戏行业里预编译的工具二进制包大小和Android/iOS的库也是蛮有用的。
原文见这里： https://jamesmunns.com/blog/tinyrocket/
strip [二进制]然后尝试使用上面的流程改造我们的 gmtools-cli 。原先我是直接开LTO+Release编译的，编出的文件大小为4.4MB（4520728字节）。
虽然我主要使用C++，但是最近也想学点现代化的新语言。初步想的是从golang和Rust里先选一个。
这两年golang在国内很火，最大的特点莫过于语言层面提供了协程支持，能够极大地简化异步逻辑地理解。我之前也接触过一点，还写了个goroutine压力测试对比我的libcopp的性能。但是golang的语法我实在不喜欢，特别是那个不管啥类型声明都是反着来，感觉在复杂的类型下会非常反人类。而且听用过的人说golang的GC还很不稳定。另外之前有新闻说golang正在准备2.0，2.0版本即将加入泛型支持，然后导致很多语法不兼容和语法分析得重写。所以我还是懒得踩这个坑了，至少等2.0出来再说。
Rust是Mozilla搞出来想拿来重写Firefox的。说实话Mozilla和Google还有点差距，导致Rust的发展还比较慢。对比起来就是感觉golang很快就提供了一些快速可用的原型给大型项目使用，标准库也足够丰富。而Rust还纠结在底层、语言层面的优化和最求极致。很多组件都还不成熟，编程设计模型也还没完全统一。
但是接触了一点Rust以后，我发现Rust真的是挠到了C++程序员的痒点，语言层面解决了用C++得费很多脑力和用各种奇技淫巧实现并且还不能完全阻止被绕过的质量控制问题，而且保留了C++很多编译期推断得高级特性。并且和C++一样，提供给你能力，但不限定你方法提供 零成本抽象（zero-cost abstractions） 或者说叫 零开销（zero-overhead）。
离上一次写Blog过了好久啦。这次拖这么长时间主要是因为最近学习了一个新的文本标记语言 – ReStructuredText 。并且重新整理了Excel导表工具-xresloader工具集的文档，写文档真是好废好废时间啊。
好多项目用ReStructuredText来写文档来着，比如cmake，再比如python。然后现在有比较容易上手的readthedocs来托管文档，和github的集成也还不错。所以我打算把一些项目的文档也迁移上去。毕竟 README.md 还是弱了些。
其实ReStructuredText也支持 Markdown 。但是使用 Markdown 写文档还是略麻烦，特别是涉及跨文档引用和多行表格的时候，而且 Markdown 各个平台的组件和扩展还都不一样，没有统一标准。在这些方面ReStructuredText就强大多了。不过这也是有代价的，那就是ReStructuredText的语法规则比 Markdown 复杂得多。
最近在抽时间整理之气的游戏服务器框架和解决方案里atsf4g-co，现在的架构是使用etcd的是atproxy。简单得说就是服务集群是分组的，每个分组有分组代理服务atproxy做组间通信。然后atproxy之间使用etcd来做分组服务的服务发现和保活，并且以此来实现平行扩容。
之前做服务间通信组件libatbus的时候也提到了有一个暂时没实现的功能，就是全局路由表的自动通知。但是这个功能的实现主要也是用于后面不同种服务间感知到哪些节点是可用的，哪些是不可用的。而且我的简单实现必然是走心跳的模式，因为心跳的形式肯定不能把心跳设置得太短，同时也要考虑网络异常抖动和断线重连和丢包，所以肯定不是丢一个心跳包就认为丢失。所以故障或者扩缩容期间的感知时间就会比较长一些。另外就是因为可能有网络孤岛问题，所以可能短期内数据不一致（当然肯定会保证最终一致性）。
再加上由于libatbus是支持多级父子节点关系的，所以变化通知和同步包就要考虑自己与父节点、兄弟节点、自己与子节点的不同关系并作不同的同步流向，会比较复杂。比如：子节点下线，既要通知父节点，又要通知兄弟节点。那么这时候给兄弟节点通知就有两个通路，一个是经由父节点中转，另一种是直接发。当然这时候并不一定和兄弟节点有直接通路。所以可能兄弟节点会收到两次通知，一次来自兄弟节点，另一次来自公共父节点。然后又会有其他问题，就是万一又收到一条冲突的消息，来自父节点和来自兄弟节点的顺序是没有保证的，这里又得加入版本机制。总的来说，细节会比较复杂，具体在实现libatbus的这个功能的时候在谈吧。
上面说的libatbus的功能暂时没实现的最重要原因是etcd可以比较完美的解决上面的延迟问题和不一致问题。缺点就是请求的消耗会高于使用libatbus的通信机制。不过这玩意本身不是高频操作，而且故障和容灾本身不是一个频发的事情所以关系不大。而之前etcd的接入是直接写死在atproxy里的，那么这次重构的目的主要就是能够抽象出模块化的工具，以便后面不同的服务可以根据需要取用。
按现在的功能划分，etcd的接入总共被分为3个模块，etcd_cluster、etcd_keepalive和etcd_watcher以及一个通用工具etcd_packer。etcd_packer用于对etcd的一些通用的打解包操作。
etcd v3版本内部的通信已经使用了grpc。本来我是想等他的grpc接口进入官方文档并且提供出的grpc的proto再接入的，可是它一直没有整理出直接grpc的proto文件列表。另外我看了一下它的proto文件里用到了一些gogoprotobuf的扩展，其他语言不一定可以无缝接入。考虑到etcd使用了grpc-gateway提供HTTP+JSON的网关层，所以我还是基于他的HTTP接入层来做。因为这里身频次不高，也没有那么在意性能。而且一组etcd服务的QPS也就在十万的级别，只要管理好连接，不要老新建立和关闭连接，HTTP的性能还是够的。
很多语言的log模块都有一个功能，就是在打log的时候能够追溯调用栈，有的时候对查bug能有点帮助。之前我也想过给我们的log模块加上C++的backtrace的功能，迟迟一直没有做主要是两个原因：一是C++的backtrace在各个平台和编译器上都不太一样，比较冗杂；二是C/C++在编译优化之后，调用行之类的信息和甚至一些函数可能就被优化没了。所以能提供的信息就相当有限。前两天刚好有朋友问有没有提供这个，所以就花了点时间整理了下适配方案。
前面有几篇blog就提到我有计划支持使用ECDH密钥交换。近期也是抽空把以前的DH密钥交换跨平台适配从atgateway抽离出来，而后接入了ECDH流程。
对DH和ECDH算法的具体原理这里不做具体介绍了，可以点击链接看。DH和ECDH的主要的作用就是在通信双方发送一些公有参数，保留私有参数，而后通过一系列计算双方都能够得到一个一致的结果。而这个运算的逆运算复杂度过高，在有限时间内不可解（至少量子计算机问世以前不可解），以保证密钥安全性。除了维基百科外，我还看到篇文章图画的很好看的：http://andrea.corbellini.name/2015/05/30/elliptic-curve-cryptography-ecdh-and-ecdsa/ 。而DH和ECDH得区别简单来说就是，前者使用了一个大素数和两个随机数，而后者使用了ECC算法和两个随机点。
实际应用中，有些加密算法的密钥碰撞计算难度反而比破解DH和ECDH要容易（比如atgateway支持的XXTEA算法，这个算法很简单所以也非常高效）。所以有些工程实践中会每隔一段时间再走一次密钥交换流程来更换密钥。
这本来是个早就可以写的分享。因为代码几周前就迁移并准备好了。而且这也是之前项目的工具，因为可以抽离出来通用化所以单独整理出来。
这个项目起源于我们之前哪个项目，客户端想要在Unity的C#里动态加载配置，而protobuf-net一方面大量使用反射而性能不太行，另一方面使用的时候得生成C#代码才行。客户端原来的做法是把消息扁平化了，使用protobuf-net得底层读写接口直接操作基本数据类型。这就失去了结构化带来的一系列好处。再加上后来我引入了跨平台导表工具，使用结构化得数据会非常方便，而手动把这个数据打散到客户端读取接口显然很浪费人力而且容易出错。所以我就干脆也使用protobuf-net的底层读写接口做了现在的DynamicMessage的支持，API设计是结合pbc和protobuf官方的API流程的。
Protobuf 的 proto3发布也有挺长一段时间了。现在很多新项目慢慢转变用proto3来开发。这篇文章主要记录一下我在给pbc写对proto3支持时的一些信息，也许对其他童鞋也有点助益。抛砖引玉一下。
pbc是云风开发的一个纯C的读写protobuf的很小巧的库，配合上它提供的lua-5.1和lua-5.3的binding可以很容易地在lua里完成对pb文件的注册和打解包。应该很多人都知道这个组件。
但是后来云风自己又发明了个sproto，然后主推在他的skynet框架中使用sproto，于是pbc就不再有功能维护了。
我们之前的也尝试直接使用了proto3，也是因为在迁移期，所以并没有使用全部的特性。但是仍然有一些向前不兼容的细节需要处理一下，所以有了这个改造
上个月，同学的公司，格奕，突然间跪了。这个月基本属于休息+四处溜达。同时空闲的时候也想整理下之前做得一些之前的做得一些小工具们。在不泄密的情况下开源出来吧（其实也就是想找github存放一下而已，也没什么特别NB的东西）。
其实很早就想把Blog迁移到静态化的博客系统了。不过一直没花时间来搞，当然主要原因还是懒。
这次下决心搞主要是因为，之前VPS迁移到Vultr，然后它的主机默认是没有交换区的。后来老是收到网站崩溃告警，每次去看都是MariaDB挂掉了，然后查了一下是内存不足。 然后，调整了几次参数，发现都不能解决问题。我这么个小站搞个高配机器显然是浪费。这种小网站都能耗尽1GB的内存我也是醉了。所以后来就干脆迁移到静态博客系统算了。
之前测出来libcopp还有一些列优化点，但是要破坏之前的API，所以整理了一下优化的想法和方案。
之前有太多的堆内存分配了，导致很多碎片。那么第一个想法就是协程对象可以分配在栈上，runner也可以分配在栈上。然后还可以加一个自定义预留长度。每个对象对齐到sizeof(long)，总长度对齐到64 Bytes。
本来是没想写这个对比。无奈之前和call_in_stack的作者聊了一阵，发现了一些libcopp的改进空间。然后顺便看了新的boost.context的cc部分的代码，有所启发。想给libcopp做一些优化，主要集中在减少分配次数从而减少内存碎片；在支持的编译器里有些地方用右值引用来减少不必要的拷贝；减少原子操作和减少L1cache miss几个方面。
之后改造了茫茫多流程和接口后出了v2版本，虽然没完全优化完，但是组织结构已经定型了，可以用来做压力测试。为了以后方便顺便还把cppcheck和clang-analyzer的静态分析工具写进了dev脚本。然后万万没想到的是，在大量协程的情况下，benchmark的结果性能居然比原来还下降了大约1/3。
前段时间看到了一个完成读比较高的协程库-libgo，里面提供了线程安全的协程实现，并且也是使用锁。本来我并没有给libcopp里的功能加锁的打算，因为上层dispatcher还是比较容易做到安全分发的，所以原来并不保证线程安全。而且线程安全这种问题单元测试比较难写，可能还得碰点运气。但是思来想去，还是为线程安全做点什么吧。反正也不是很复杂。
由于我并没有给utils加互斥锁的跨平台适配，所以先就直接用了自旋锁，来锁住需要考虑线程安全的地方。其实需要加锁的地方并不多，无非是管理器的增删查和task的next函数需要加锁。这些逻辑都很短，功能也很简单，并不会占用太多时间，所以自旋锁的问题也不大。而且以后真发现有问题，换掉也不是什么难事儿。
之前的版本发完，有空来更新一下之前的gcc和llvm+clang工具链的编译脚本了。其实GCC 7是才release没多久但是llvm 4.0发布其实有一段时间了。
在写这篇文章前，我突然想到以前流行了一段时间的服务器面试题：当一个BUG只有几百万分之一的概率会出现，怎么办？这个问题在这个BUG里只是毛毛雨而已，因为这次的BUG的出现概率是夸张的三亿分之一。
最近看了下最新版本的cmake的文档，很惊喜地发现他已经支持直接设置Android和OSX的一些变量了，然后有瞄了一眼NDK，发现里面现在也停工官方的cmake支持。