0x00

前段时间专门抽空做了一个小工具，也就是这里要讲的主题：anvil

一开始做 anvil 的动力很简单：某次尝试体验一下 Linux SignalFD 功能时想直接使用 ezio 的 EventLoop 作为基础事件循环，同时项目使用 cmake 管理。

为了省事，我直接从 ezio 的项目里抠出来 CMakeLists.txt 和几个自己写的 .cmake 文件，就地修改。

但事实证明哪怕这样，改动量也不小，原因大体是因为：cmake 里（非函数内定义的）变量作用域是全局的，通过 fetch-content 功能引入的依赖在 add_subdirectory() 后的模块里也能看到上一层定义的变量，因此为了防止一些控制型变量发生冲突，我都在前面加上了对应的模块前缀。

所以我面对的就是一大坨变量名的更换，以及少部分声明/属性的调整。

考虑到大部分的文件内容都是可以模板化的，而手动“实例化”不仅费事还很容易出错，所以我就很自然地萌生了写一个工具自动化这个过程的想法。

0x01

在经过一两天的短暂思考后，我大致确定了这个工具的定位和需要实现的基本目标，总结起来有三个核心点：

1. 辅助 cmake 而不是试图替代它或深度封装
2. 内建一个轻量型的依赖管理功能
3. 配置化的生成 & 构建流程

首先，第一点是重中之重。

Programming Languages

Destructors that throw

C++ 11之后的 destructor 默认是 noexcept，如果有 active exception 逃逸出 dtor 会直接触发 std::terminate()，即使外部有 catch handler。可以用 noexcept(false) 显式关闭。

因为 stack unwinding 是可以嵌套的，一个精心设计的场合下（见文中例子），可以做到多个 active exception 不在一个层次里，因此也不会触发 double-exception situation。

Who calls std::terminate?

an exception leaves out from main function

an exception leaves out from initial function of a thread

an exception leaves out from dtor (since c++ 11 with noexcept guarantee)

大部分人应该都知道 DNS 协议，以及它的用处。但是考虑过自己动手写 DNS message transmission 的应该不占多数。

我们不妨考虑如何自己实现一个简单的 DNS client，完成基本的 domain name query and response parsing。

因为 DNS 协议通常使用 UDP 作为其传输层协议，而且数据包是二进制包，所以实现一个这样简单的 demo 考虑用 golang 可能会省事儿不少。

DNS Message Format

大体上 DNS 不是一个复杂的协议（虽然各类坑实在不少），所有的消息，不管是 query 还是 reply，都共享一个消息格式：

1
2
3
4
5
6
7
8
9
10
11

+---------------------+
|        Header       |
+---------------------+
|       Question      | the question for the name server
+---------------------+
|        Answer       | Resource Records (RRs) answering the question
+---------------------+
|      Authority      | RRs pointing toward an authority
+---------------------+
|      Additional     | RRs holding additional information
+---------------------+

• Header：消息头，包含一些参数、标志位
• Question：包含 query 的信息，例如需要查询的 domain
• Answer：reply 的信息
• Authority：如果有信息，则表明应答的服务器是 ultimate authority server。别忘了 DNS 服务器是树形结构，通常终端用户查询的 DNS 服务器都是 local DNS server。
• Additional：服务器传回的一些额外数据，非用户显式需要的

对于一个 query message，Answer section 是空的；而对于一个 reply message，Question 保存着对应 query 的数据。

一般而言，终端设备收到的 reply 消息里，Authority 和 Additional 是空的。所以下面会跳过这两个 section 的描述。

ezio Buffer 一开始的时候只为 read, write 和 peek 提供了从 int8_t 到 int64_t 的函数重载，如果需要处理 unsigned integers，那么就需要自己额外做 static_cast。

ezio 的主要客户藏心同学早前抱怨过这个问题，并且同时建议我加上对 float/double 的浮点数支持。

对于这个建议我一开始是抵触的：

• 自己 cast 又不是不能用，额外加重载支持三个操作工作量都要翻一番呢
• 浮点数的 binary serialization 本来就是很难跨平台的，不是每个环境都（虽然大部分）要求使用 IEEE 754 spec。如果真的需要直接把浮点数存到网络包里，自己直接操作 underlying binary layout 不就好了…

于是藏心同学一开始开的 issue 我一直没理他，于是最后他自己关掉了…

等到我自己动手写一个 socks4a proxy 的时候我发现，自己 cast 真的是…太蛋疼了…而且代码看上去还非常丑，大面积的 static_cast 制造了相当一部分内容噪音。那会儿我大概有点理解藏心同学的内心感受。

于是我思考良久，打算改造 Buffer 的这部分接口，以支持绝大多数 integer types，顺带也增加入 floating piont types 的支持，这样 read, write, peek 就基本支持了绝大多数 arithmetic types。

通过直接增加重载是我极力避免的，因为除了接口签名外，大部分实现几乎是一样的，不外乎：

• 如果是单字节，直接写/读操作
• 如果是多字节，首先字节序转换，然后做写/读操作
• 如果是浮点数，首先按照对应字节大小的整数类型解释内存，然后参考普通整数的处理

于是自然而然的想到直接将函数做成 function templates 来增强语义。

Networking

The State of Browser Caching, Revisited

对于网络编程学习而言，尝试实现一个 proxy 是一个很好的途径。因为一个 proxy 对于 clients 来说是 server，对 remote servers 来说又是 client，一下就覆盖到了网络编程的两个大块。

同时，需要管理/协调两侧的连接对如何正确的处理网络连接的关闭也是一个挑战。

Google API Design Guide

基本上 可以看作是 Google 开放的 API 设计指南。

大体上，Google 对外公开的 API 设计有如下几个特点：