背景

amavisd 是 MTA（例如 postfix）流行的 content-filtering 模块，可以提供垃圾邮件试别过滤、病毒邮件检测隔离等功能。

spamassassin 则是 amavisd 使用的垃圾邮件模块。

在目前主流的 Linux 发行版上，这两个系统都会以 systemd 管理的服务运行。

在系统集成过程中遇到一个神奇的问题：amavisd 和 spamassassin 服务会定期挂掉，journalctl -fu 的日志都提到了

• config: no rules were found! Do you need to run sa-update​?

的错误内容

处理

解决步骤：

1. 检查 /var/lib/spamassassin/ 目录下是否有一个对应版本的目录，例如 3.00402
2. 如果有的话，删除这个目录
3. 然后先后重启 spamassassin 和 amavisd 服务

在阿哔呆了 1860 天（2016/04/11 – 2021/05/14）之后终于完成了跑路，跑路到现在也一个多月了，也可以从一个“前任”的角度吐一吐槽了。

其实一开始我预期至少在阿哔待到2022年下半年再考虑是否跑路，主要原因是当初和媳妇儿（那会儿还是女朋友）约定是30岁之后再考虑回杭州工作，毕竟那会儿杭州能叫的上名号的互联网公司给我的印象都不好，印象里也没有什么知名的外企。

作为一个曾经的资深 Windows developer，Windows HANDLE 一个不引人注意的但是绝对值得引起注意的地方是，它的无效值表示是不唯一的。

除了最常见的 NULL 之外还有一个 INVALID_HANDLE_VALUE，并且即使是在数值上这两个东西也不一样。

如果要为 HANDLE 写一个 C++ RAII Wrapper 那么必须要考虑这个点，比如 Chromium 就是这么做的。

Chromium 的这个设施早在 C++ 11 之前就有了，并且经过多年来的迭代已经变得异常复杂；如果你自己需要这样一个东西，又无法从 Chromium 这种工业项目中抽取一个组件的话，只能考虑自己实现。

但是要写对一个工业强度的 handle-wrapper 并不容易，同时还要考虑到通用性和实用性，比如可能后续要支持 fd/socket，Windows HDC 等各种奇奇怪怪的东西。

所以能否用 std::unique_ptr 来作为基础实现，针对一些特定细节做泛化？

这就引出一个问题：如果希望用 std::unique_ptr 来作为 HANDLE 的一个 RAII 包装，如何正确判断一个 handle 是否 valid？

更进一步，问题还可以变为：如何用 std::unique_ptr 管理 pointer-like 的资源？

系列第一篇文章里说后面会给出一个满足 RFC 4122 的可用实现，并且那会儿是打算讲一讲实现中一些需要注意的坑和有意思的点。

但是因为3月份开始就忙着准备面试，清明结束后的两周基本不是在面试，就是在准备面试；一直到五一回了趟温州老家才有比较充裕的时间把 uuidxx 的核心逻辑写完。

拉锯到现在一开始的冲动都已经被消磨得不剩下多少了（可能还是因为我比较懒），所以我不打算把具体的实现部分展开，有兴趣的可以自行查阅源代码。

Repo 地址在 https://github.com/kingsamchen/uuidxx

因为这次换工作我有很多槽点想吐，所以后面我会专门写一篇文章讲一讲。

这篇应该不会鸽，毕竟喷人挺爽的一件事。

这一篇来讲 v3 和 v5 的实现。

这两个实现要求使用方提供：

• 一个称为 namespace 的 UUID
• 一个叫 name 的数据块（不限于字符串）

然后利用一个 hash 算法算得结果，作为目标 UUID 的基础数据（还需要额外设置 variant 和 version）。

即，对于 v3/v5 的实现，本质上是

1
2
3

uuid = hash(namespace, name)
set_variant(uuid)
set_version(uuid, ver)

v3 和 v5 区别在于，前者是用 MD5，后者使用 SHA-1。

并且可以发现，对于相同的 namespace 和 name，生成的结果 UUID 是一样的。

这个就是 v3/v5 版本的特性。

借用 RFC 的描述就是：

• The UUIDs generated at different times from the same name in the same namespace MUST be equal.
• The UUIDs generated from two different names in the same namespace should be different (with very high probability).
• The UUIDs generated from the same name in two different namespaces should be different with (very high probability).
• If two UUIDs that were generated from names are equal, then they were generated from the same name in the same namespace (with very high probability).

所以 v3/v5 的版本又被叫做 name-based implementation

上篇介绍了 UUID 的格式和 v4 的实现，这篇讲 v1 & v2 的实现。

v2 版本是 v1 上衍生出来的，而 v1 因为涉及到时间戳，又称为 time-based implementation。

实现 UUID v1

v1 除了常规的 variant 和 version 部份外，还涉及三个部分：

• timestamp，需要 60-bit 通常用 64-bit 容纳；非寻常的 Unix Timestamp
• clock sequence，需要 14-bit，通常用 16-bit 存储
• node identifier，48-bit 和设备相关

下面逐一解释这三个部分。

0x0. UUID Timestamp

和常见的 Unix 时间戳不同，UUID 时间戳记录的是，自 1582-10-15 00:00:00 至今的 100-ns 数。

1582年10月15日的零点是格里高力历开始的时间，这个时间也是 UUID Epoch Time。

UUID 时间戳的分辨率（resolution）是 100 纳秒，即每 100ns 为一个 tick。

现代编程语言都可以获取 unix 时间戳，因此可以先获取 unix 时间戳，然后加上两个 epoch time 的差值；这个差值是个定值，等于 122192928000000000。

注意：获取时间戳时需要注意系统或者语言库能提供的分辨率。

0x1. Clock Sequence

因为引入了时间戳，所以存在可能由于时钟回拨、闰秒，甚至因为系统提供的时钟分辨率不够导致使用了重复的时间戳。

另外 node identifier 也有可能被改变。

所以为了尽可能保证 UUID 的唯一性，引入了 clock sequence。

注：RFC 4122 没有规定 UUID v1 必须要使用 steady clock，所以使用能够被回拨的 system clock 也是允许的。另外，即使使用了 steady clock，机器在两次启动之间也可能调整了硬件时间，一样可能会导致回拨。

Clock sequence 一开始会被初始化为一个随机值；之后如果某次获取 UUID 时间戳发现 <= 上一次的时间戳，就会自增 clock sequence。

clock sequence 通常会设置为一个无符号数，以确保溢出 wrap-around 的行为是确定的。

数据格式

UUID 是 Universally Unique IDentifier 的缩写，本质上是一个 128-bit (16-byte) 长的标识符，可以用32个16进制数表示，并且通常以如下形式展示：

1
2
3
4

// 每组字符长度分别是 8-4-4-4-12
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
              ^    ^
              M    N

上面 M 和 N 出的数字分别表示了这个 UUID 使用的 version 和 variant；具体下面展开。

HEX 字符存在大小写，按照 RFC 4122 要求，UUID 输出时 'a'-'f' 应为小写；但是在作为输入时大小写不敏感。

因为 UUID 的生成不需要中心管理节点 (central authority)，是天然分布式；也正因如此，没有一个验证 UUID 是否有效的方法，最多只能验证是否满足数据格式要求。

0x0 Variant

上面 N 处的 HEX 的 3-bit MSB 指明了 UUID 使用的 variant。

Variant 决定了当前 UUID 其他的 bits 如何 interpret。这里的 bits 也包含 M 处指示 version 的那部分。

语义上讲，variant 更适合被叫做 type