之前版本的 cincau 是一个 MVC 模式的 HTTP server，内部认为一个业务逻辑单元（controller、或 page）可以匹配多个 URL 数据请求，一次 URL 请求将抽象为一个 request 实例给 controller 处理，controller 将 response 对应的 HTML，而 model 层则是 SVR 内部数据源的抽象。
所以 cincau 的 request 是一次 HTTP URL 请求的数据集合，比如请求的 method、path，header key/value 数据。
但后续 cincau 将支持 WebSocket，本来 WS 也是 HTTP upgrade 而来，只是 WS 是长连接，在 cincau 内部，希望继续复用已有的 MVC 模式，复用之前的 request 结构，并且，WS 和 HTTP 共用一个端口号。
大体上没什么问题的，在框架设计上，可以特例 HTTP 为仅有一帧的 frame，并指定专用的 frame type，而 WS 可能一次带有多帧，区分 PING、PONG、TXT、BINARY 的 frame type。
但作为长连接的 WS，跟 HTTP 的最大的不同，在于
以上两点，都将复用提供 request 给 controller 的函数（参数不变，但不同状态下 request 带有不同的标记），比如使用 isPeer() 区分是 CNT 请求过来的，还是 SVR 主动触发的，以及使用 isDisconnect() 来区分 CNT 是已建立链接，还是掉线了（可能是 CNT 的 TCP 主动断开，或者 SVR PING 后一定时间内未收到 PONG 回应，SVR 主动 close 了 TCP 导致）。
大概是上面这样的想法，感觉应该可行。
然后在 cincau 增加了 WebSocket 的相关 demo，实现了一个简陋的聊天室。
2024 年 6 月 30 日后，GitHub Pages 默认使用 GitHub Actions 拉起 Jekyll 来构建网站（需自己动手配置），若想恢复之前的分支部署，需要在发布工程根目录增加 .nojekyll 文件做标记。
具体可以访问这个链接。
我用的是分支部署的方式，所有文件都会部署为静态资源。
没有跟上时代步伐使用 Jekyll 的原因是，我最开始用的是 EmacsWiki 来通过 wiki 生成静态页面，后续 Emacs 不断更新，但 EmacsWikiMode 已经渐渐没人维护，我就转而使用 CommonMark 引擎的变体 cmark-gfm 来渲染 wiki，然后自己写了一个 build 管理脚本去控制页面渲染流程。
《更换 Markdown Engine 为 cmark-gfm》有详细的描述。
下载的 GTA5，大部分的时间，都是富兰克林开摩托，点开秘籍后，打爆 LSPD 的车胎后调戏，或者就直接调戏，以及各种破坏后，带着 4 星、5 星通缉逃逸（即便在地面上，还是有概率逃逸成功的）。主线的进度没怎么关注，但后面黑悟空发售了，我这边主线还没打完，如果立即切换游戏，就太可惜了，于是继续了之前的主线。
主线其实要认真推起来，也挺快的，最后结局选 C，三人互相帮助，免于一死。
最近看了一本书《1421——中国发现世界》，作者是加文·孟席斯（原英国海军潜艇编队指挥官）。
论证中国早在明朝郑和时，就已经进行了大规模的环球航行，发现了美洲、大洋洲、南极洲等，并出了海图。
哥伦布、麦哲伦、库克等就是靠着这些海图，才进行的环球航行。其舰队规模，人员配置比郑和船队小多了，如果没有这些海图，其舰队规模根本无法支撑其环球航行。
作者花了 14 年研究，给出了许多论据，比如船队沿路经过留下的遗物、碑文、沉船、哥伦布等人的信件等。
有种小时候已熟读的历史被点了刷新的感觉。
🐼
自从 cincau 支持多进程的方式之后，同步数据的能力最开始是通过不同 worker 的 UDP socket 来传递的，即时性有限，大概固定几秒钟去同步一次，而且如果数据量大了也是个问题。
相比较下，即时性的问题才是主要的，比如其中一个 worker 接受了用户的登陆状态，用户的下个请求是另外一个 worker 来服务的，此时 cookie 的 session 信息根本还没同步过来，就成了问题。
当然这个问题也有粗放的解决办法，比如用 SQLite 来同步，但是这种 Key/Value 的信息也使用 SQLite 觉得还是太重了。
这里插播一句，之前了解过使用 mmap 来同步数据的 MMKV，因为 mmap 同样可以用来多进程同步数据，因此这个库也是可以多进程同步的，感觉这个库可以解决 95% 以上的同步问题，其他的例外情况，我下面会说。
在展开其他方案之前，我得检讨一下，一开始走了很多的弯路，虽然了解到需要使用一些多进程同步手段，比如最开始的 socket，比如可以使用 Linux 消息队列，以及 mmap，但是我把这个问题想得简单了，而且一开始我也没想起 MMKV。
比如我一开始就选择了 mmap，想做一个 mmap 的有序字典，我手头有 MIT LICENSE 的 AVL tree 代码，相比之下 MMKV 这种 bitcask 结构的数据库，是无序的，除非你 dump 出来所有的 key 再排序，否则你无法快速拿到按照 Key 排序的第一个节点，而 AVL tree 对 Key 排序的方案就可以。
可是已有的 AVL Tree 的方案，其对节点的引用是指针的，虽然 mmap 只管映射内存区域，但是不同的进程，其映射的内存区域很可能不一样，比如我使用的 LuaJIT，除了我自己主动调用的 mmap，其他不知道什么原因，也有不少的 mmap 调用。导致如果使用 AVL tree 的方案，除非是能保证每一个进程 mmap 过来给 AVL tree 使用的内存块，采用同样的起始地址，否则后续的指针计算，指向的节点地址就有问题。
虽然理论上，我可以将进程空间的一大段都交给这个 AVL tree 共享内存的方案，但是实际做起来其实也不方便，而且 mmap 这个系统调用其实很频繁，用 strace 就可以看到，其他的一些文章也有介绍。
所以，不得不将 AVL tree 的指针引用，改成 int32_t 的间接引用，这里的 int32_t 分成了高 16bit 和低 16bit，其中的高 16bit 用于 index 内存区块，低 16bit 用于 index 每个区块内的位置，byte offset。
之所以这么做，是因为内存块是动态申请的，不会一下就申请完所使用的内存，而是根据使用量逐步申请，虽说是共享内存，也总得使用实际内存空间的嘛。
另外这个 AVL tree 的方案相比 MMKV，其实有很大的限制，因为考虑到不想做 bitcask 那样的回收方案（简单点做），因此设置了限定最大的 Key/Value 长度，这个是调用库在初始化的时候就得进行设置的。
比如 Key/Value 的最大长度是 64 字节，其中 Key 是一个 timestamp 占 32 字节，后续的 Value 是一个 MD5 的 hash 占 32 字节，这里还可以插播一句，可以将这个 Value 作为 MMKV 的 Key，这样就实现了 MMKV Key 的有序，回应了最开始说的 95% 的应用场景。不过这里也得提一下，MMKV 还可以设置每个 Key 的过期时间，所以这个 95% 的应用场景，实际上还可以扩大不少。
回到刚刚的 AVL Tree，所有需要同步的数据都存放到 mmap 的内存区块中，每个进程都有对 AVL Tree 的引用，以及自己保留一份已经打开的内存区块列表，当别的进程因为塞入更多的数据申请了新的内存区块，其他进程在进入库调用的时候，检查到这个场景，将新的内存区块也 mmap 到自己的进程空间上。
因为每条数据是固定的长度（最大 Key/Value 长度），所以 AVL Tree 的 index 间接指针会忽略掉不同进程内存区块的起始地址不一致的情况，只关注内存区块的序号，以及每条数据对应内存区块的偏移字节，当这个内存区块已经映射到进程空间上后，对 index 的数据的读写就没有障碍了。
在实际使用中，当内存空间不足时，申请内存区区块序号（2^16个），映射内部的节点地址偏移，两者揉进每个节点的唯一 index，当删除节点时，节点可以回收而不需要整理内存区块，比如将该节点的 index 保存到未使用空间列表节点的 right 指针（间接指针）中。
上面说完了 mmap AVL Tree 的使用场景、面临的问题，提出的解决方案，和该方案的限制，下面列出来了一些实际跑通该场景的有趣细节：
细节太多了，当然相比较 SQLITE，上述两套方案的效率会高很多。
MMKV 已经很成熟，多平台都能支持，AVL Tree 是我当初小看了 mmap 导致的，而且有先天的短板，虽然说提供了有序 Key 的能力，但这个是在约束了最大 Key、Value（每条数据都是这个最大长度）来达到的，因为可以避免替换 mmap 共享的内存区块。
研究了一下 WebSocket，在 HTTP/1.1 之上，提供了一个双工长连接，通过 header 的 Upgrade 来完成协议升级及参数交换，之后就都是 websocket 的 frame 了。其最基础的协议描述在 RFC6455，压缩部分的扩展在 RFC7962。
之前研究了一下 C 写的 Websocket，验证了一下是可以正常工作的，但它 frame 的解析部分不好单独摘出来。
client 端的 html + js websocket data send/recv 其实很好写，browser 本来就有 WebSocket 的接口给调用，拉起本地的一个 html 就行了，但是 browser 无法指定 http header 的参数（包括 ws extension），发送 text、binary 的 frame 时，是通过 js 的 string、uint8 array 来指定的。
想着找一个可以直接提供解析 websocket frame 的库，虽然找到了 C 写的 wslay，但是实际使用过程中，感觉使用实在是繁琐。
比如 websocket frame 的结构如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
回到之前说的 wslay，霓虹国写的东西太复杂，居然 header 没检测全都能返回好几种错误，我感觉这部分其实可以简单点，比如 header 都解析不了的时候其实可以提示数据不足（毕竟 header 数据都不足），缺点是放弃了一部分错误的检查。
在 HTTP/1.1 的协议升级到 websocket 之前，header 需要交换一些数据，比如 client 会发送如下的字段
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: fSQMpewdgSIz1IhuhL3ERQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
说到 permessage-deflate，server 在 deflate payload 后构建 frame 时，需要设置 rsv1 bit 为 1，要不 client 会忽略 extensions 的描述。
还有 server 在 inflate frame payload 时，实际上认为不断喂进来的 payload 是连续的 data stream，因此不需要做 inflateEnd。
这个感觉也跟 HTTP/1.1 的实际处理类似，实际每个 http requet / response 都是一个单独的 inflate / deflate stream，websocket 升级了协议后，可以认为不断发送过来（出去）的 payload 是没有结束的 http body 数据，因此不需要结束这个 inflate / delfate stream。
其他比如 ping、pong、close frame 类型没怎么研究，不过感觉 close 没啥作用，也许是用于实际关闭 tcp 链接前的一个处理吧，也许给调用层处理，在 websocket frame 这一层感觉没什么必要，毕竟无论如何总是要处理没有发送 close 的资源注销的，那又何必多此一举要这个 close 呢。
这个月忙得要死，继续遗迹2水一篇。
郁闷的是还没通关，感觉应该是最后一关了吧，那个守卫太难打了，而且我的 6600xt 显卡即便用最低特效感觉都挺卡的，玩得有点吃力。
于是我就回过头去肝装备和等级，收获有一些，但不多，估计要年后才能继续这个最终 BOSS 了。
另外，这个游戏有些流程挺坑的，它的大部分地图都是随机的，有不同的版本，比如我进去的涅鲁德，如果最终不打守卫，或者不插钥匙到主控台的话，其实后续是可以过来场景下选择其他的小地图，继续肝等级和装备的，但是我当时不懂呀，钥匙随机就插入主控台了，也没听到从未见过的保管人说了啥，然后继续断断续续肝了涅鲁德的守卫人后，这个场景差不多关闭，只剩下一个宇宙的一角，只有一个录音机的叙事声音，其他场景都被破坏无法进去玩了。
这也太郁闷了，然后我之前不知道这个插钥匙的影响，没有备份角色资料，以及游戏世界的资料，于是就再也回不去刚开局遇到的涅鲁德了，只能开冒险模式单独玩这个章节，重开的这个章节也是随机的，还不是之前原来的那个。
另外，不知道是不是魂系游戏都这样，就是等级、装备上去后，之前比如在我遇到的第一个场景喜乐宫，我当时肝了好几个小时才通，反正拿的远程很难打，现在等级装备上去后，就感觉太容易了，刷经验没有任何乐趣可言。
网上搜了一下，貌似通关一次后，可以选择将世界升级为二周目，难度会上升一个级别，之前的老头环也是如此，有这样的一个选项，不过我没升级，感觉打同样的场景可太没意思了。
老头环我的操作熟练度很差，几乎可以说是靠着 TB 买的魂升级属性硬给拗过的；相比下遗迹 2 因为大部分的地图有随机场景，估计继续肝 2 周目的感觉会好一些吧，不过我现在还没通关一周目，后面再说吧。
法环（艾尔登法环）是我第一次玩魂系，进入游戏的大树守卫者就已经让我崩溃了，后面就是熟悉的操作，上 TB 买游戏内魂币，升级人物属性， 后面的难度确实大大降低，很容易就搞到了厉害的武器，没多久就通关了。
不过也因为走了捷径，后面的游戏性其实没有那么强了，很少死了。
也看过不少厉害的游戏玩家，那个操作，我实在是学不来，罢了罢了，我只是通关走过场。
之后又看到了遗迹2的介绍，也算是一个魂系，配合 FPS 之类的远程打击，以及职业切换（还没玩到这个部分，不熟悉），那就入手试试吧。
然后花费了一个晚上，才算入门，死了四五十次都有，这次倒没想着要上 TB 买游戏币升经验，反正就试试看吧，看独立玩这个魂系能否进行下去吧， 感觉游戏性还是可以的，只是要计算的东西不少，比如弹药用量就有受的，因为有的枪射速太快了，伤害反而低，感觉升级武器的系统还是挺重要的， 武器反而不需要随便换，没那个必要。
相比法环，没有那么在意近距离的格斗，那个实在是太难了，除非把脑子和手都训练成一块，肌肉记忆，要不哪里来的及。
所以攻击力、弹药用量比较重要，可以继续搞搞。
最近装了一套 AMD YES R5-5500，内存金百达银爵 3600 长鑫 Adie，主板是爱国嘉 B450M K，风扇利民 AX120 R SE。本来是看中主板的 PBO 超频和内存 XMP 超频的，但是内存默认是 2666，XMP 也才 3200，PBO 默认的话，感觉差点意思，反正只依赖主板提供参数的话感觉不大够。
在 B 站学习的过程中，我找到了内存超频的小参可以升到 4133（5600g内存超频(3600至4133)金百达银爵3600长鑫A die 可以直接抄作业，手把手），经过了系统自带的内存诊断和 AIDA64 内存测试都稳稳的。
在内存 4133 和 CPU 主频 4.5G 的情况下，此时 CPUZ 分数可以到 610 左右。
CPU 主频定到 4.5G 参考的是（（新）r5 5500+c9bjz+5600xt超频视频详解（技嘉b450m小雕），含2k分辨率游戏实测），待机温度 40+，但是 5500 积热，FPU 单烤温度一下就到了 80，此时风扇散热片还是凉的，如果机箱风道好的话，也许可以抗住吧。还有就是 Core Temp 上面电压总是固定为 1.35v，感觉有点高不知道为啥。
用了一阵，还是将 CPU 改成了 PBO Advance 来控制，教程（技嘉b450m主板锐龙5000系列开PBO2教程），PBO 定格后频率在 3.6 到 4.45 之间浮动，电压 1.2x 附近感觉还行，FPU 单烤温度要比定频 4.5G 好一点点。
显卡也是老古董 10 系，正常用整机功率 50W ~ 70W 这样，FPU 单烤时会飙升到 130W，不管是定频 4.5 还是 PBO Advance 定格都一样。
深圳秋天用了一阵，感觉还行，希望夏天应该没事吧。
之前用了大概半年的 RX580，黑苹果 4K 输出，感觉挺好，只是机器有点浪费，毕竟 CPU 和内存都还不错的，想搞个双系统游戏主机，买了 1T 的 SSD，顺利安装上了 Win11，这样短板就来到了显卡 RX580。
PDD 上比较了半天，觉得 RX6600-XT 也不错，价钱不错，性能主流，就入手了。也用了一阵子了，感觉不错，相比 RX580 耗能要少，散热压力小一些，关键是主流游戏 1080、甚至 2K 都还行，现在闲暇时间，不少都是切换到 Win11 下玩游戏了。
黑苹果可加上 NTFS 的 KEXT 驱动，读写 Win11 分区不成问题，所以对于黑苹果来说，也算是扩大了硬盘容量。虽然 SATA 3.0 600MB 的速度远不如 M2 的速率，但总比没有好嘛，可惜主板是 ITX，只有一个 M2 的接口，要不谁不想接双 M2 呢。
之前的 ITX 机箱散热不大行，于是换成了一个大一点的机箱，一整面都是钢化玻璃，算是海景房配置了。
这个便宜的机箱虽然有开机键，但是没有电源指示灯，主板是否上电，得仔细看风扇才能知道，这样子不如搞个 ARGB 灯呢，再说之前都没玩过。
主板是支持 ARGB 灯的，PDD 上也很便宜，不到 10 块钱一个的 9cm 风扇就有带灯的了。
而且主板打开 ARGB 后，默认配置的 ARGB 幻彩就很好看，各种颜色无缝转换真的挺好看的，windows 系统下面不用设置，我就用默认的，但是问题来了，重启进入 mac 后，幻彩变成了单色灯，如果再重启，灯就不亮了，估计是 mac 下面覆写了 ARGB 灯的配置，而主板支持在操作系统上面做配置。
但是主板没有提供这个比如说固定配置，或者只读的模式，防止操作系统覆盖，这个就很蛋疼了。
我是找了不少 mac 下面配置 ARGB 的，貌似华硕在 mac 下有专门的 app，但是我这个牌子的没有，而且我这个牌子的在 windows 下使用厂商提供的 ARGB 软件，都无法设置 ARGB 灯，感觉都没用心做，至少几家主板厂家上层配置的 app 是不通用的。
还好 PDD 上面有独立供电，不依赖主板 5v3 针 ARGB 接口的控制线，还支持无线设置，我没买无线的，买的就是几块钱便宜的线控设置，线控设置好后，重启也不影响。控制线的电源可以是 USB、大 4 pin 或者 sata 线，另外一端就直接当成 5v3 针的公口，风扇的 ARGB 控制线直接接了上去，避免了主板、操作系统的介入操作，配置直接在线控按钮上切换就好。
默认的颜色不好看，换了好几种，终于换到了幻彩，那就可以了，大赞🥰