lua 中 40 字节以下的字符串会被内部化到一张表中，这张表挂在 global state 结构下。对于短字符串，相同的串在同一虚拟机上只会存在一份。在 skynet 中，有大量的 lua vm ，它们很可能加载同一份 lua 代码。所以我之前改造过一次 lua 虚拟机，[让它们可以共享 Proto] 。这样可以加快多个虚拟机初始化的速度，并减少一些内存占用。但是，共享 Proto 仅仅只完成了一半的工作。因为一段 lua 代码有一很大一部分包含了很多字符串常量。而这些常量是无法通过共享 Proto 完成的。之前的方案是在 clone function 的时候复制一份字符串常量。或许，我们还可以做的更进一步。只需要让所有的 lua vm 共享一张短字符串表。首先要考虑的是并发冲突的问题。如果我们使用开散列 hash 表，预先分配好大量的队列（比如 128K 个），那么就可以只针对 slot 加读写锁。鉴于大量短字符串都是在加载代码的时候构建的，同样的代码不需要构建两次。所以这个读写锁的写频率会非常的低，性能应该不会有什么问题。比较麻烦的如何回收那些不再使用的对象。由于共用同一份 TString 对象，所以不能简单的为每个字符串记数（每个引用它的 vm 加一）。我最初的想法是永远不再释放那些短字符串，因为看起来总量并不多。但在公司里讨论以后，很多人还是很担心。如果程序要运行数个星 ...继续阅读 (94)

Lua 是一门嵌入式语言，和 host 的联动非常重要。Lua 使用 userdata 来保存 host 里的数据，userdata 非常强大，可以有 metatable 还可以关联一个 uservalue ，可以封装一切 C/C++ 对象，非常强大。但有的时候却稍显不足，似乎缺了点什么，导致一些简单的需求要用很繁琐的方式解决。有个想法想过很久，今天动了念头用英文写了一遍投递到 lua 邮件列表里去了。那就是，如果我们可以给 userdata 的值关联一个整数，而不是把 uservalue 关联到 userdata 的对象里那样，可以简化很多事情。看这样一个例子：如果我们有一个数据结构：struct foo { struct foo1 foo1; struct foo2 *foo2; };如何保存到 lua 里被 lua 引用呢？通常我们使用一个 userdata 封装它：struct foo * f = lua_newuserdata(L, sizeof(*f));但是，如果我们想进一步引用这个结构中的一个子结构怎么办？即，如果我们在 lua 里有了 userdata foo, 希望可以通过 foo.foo1 引用其子结构 foo1, 用 foo.foo2 引用 foo2 怎么办？当然，我们先要给 foo 配置一个 metatable 并实现 index 元方法。这样在语 ...继续阅读 (88)

起因是skynet 的一个 Issue，同时，这两天我们正在开发的一个项目也反应貌似有内存泄露。我觉得两件事同时发生不太正常，就决定好好查一下。其实在 skynet 里查内存泄露要比一般的项目容易的多。因为 skynet 天生就分成了很多小模块，叫作服务。模块申请的内存是独立的，内聚性很高。模块的生命期比整个进程短的多，模块的规模也不会太大，可以独立分析。一般说来，如果有内存申请没有归还，应该是 C 模块里的 bug 。而 skynet 会用到的 C 模块也很少，一旦有这样的问题，很快就能定位。skynet 实现了一个内存管理的钩子，用于按服务分开统计内存的开销。代码在 skynetsrc 目录下的mallochook.c文件里。我建议同事做这样的修改：在每次内存分配释放时，按当前服务的 handle 做文件名记录 log 。这里有考虑一点点多线程并发的问题，但发生的概率很少，如果只是做临时的调试，可以暂时不理。因为同一个服务的分配行为不会并发，只有很少的情况释放在另一个线程中。如果发生了，会导致写 log 遇到一点错乱。比较麻烦的是，在 hook 里第一次写 log 打开 log 文件有可能由 crt 触发 malloc 导致死循环。如果要避免这种情况，需要加一个 tls 标记，在进入 hook 后就设置上标记，避免被重入。加上十多行代码后，内存管理的 log 就可以正常工作了。 ...继续阅读 (71)

之前写过一篇为什么 skynet 提供的包协议只用 2 个字节表示包长度里面提到, 如果有体积很大的消息传递需求，那么应该在上一层去处理。从另一方面来说，我们应该正视长消息的处理，而不应该将其和普通（较短）消息的处理混为一谈，在底层抹平之间的区别。最近，需求就来了。我们的一个新项目希望在 cluster 间通讯的时候，可以支持较大的消息。原本提出需求的同学想自己修改 skynet 的 cluster 模块，修改底层协议的包头长度的。我即使阻止了他，并自己动手做了修改。简单说，就是在上一层的 cluster 协议上，增加了长消息的标识。由于之前就有一个字节做标识，其实并没有对协议做太大的修改。当消息（无论是请求还是回应）太长时，就分开打包，并在标识字节上表明这只是一个完整消息的一部分。然后在接收方合并即可。一开始我并不打算修改 cluster 依赖的socket channel 模块，让分开的每个小包都有一个独立的 session 。做了一半以后，发现对 socket channel 做一些增强（不应该之前的接口）会更好一些。而且可以很容易利用上之前做的 socket 低优先级队列这个特性。新的修改我暂时提交到一个叫 multipart 的 skynet 独立分支上，欢迎感兴趣的同学 review 。同时，我把 skynet 之前的两个含义不明确的内部宏重新定义了，去掉了之前对内部消 ...继续阅读 (153)

这两天都在忙一个事情, 把我们的一个新游戏提交到 steam 绿光计划上。去年底开始，公司里就有两个人开始在忙一个小项目。最初的一个月，他们只是做了一个原型，本来打算演化成一个手机游戏，作为 2015 年公司的新项目去推广的。这个原型只有一个简单的战斗动画，提出想法的同学是一个格斗游戏迷，他只是想简化格斗游戏里的操作，提取出一些核心乐趣带给大众玩家。当然，他同时也是一名优秀的美术设计人员，所以原型做的非常绚丽，一下子就吸引了公司里很多人。对于这款游戏做出来后如何盈利，最初的两个开发人员（一个美术和一个程序）一点想法都没有。他们没有沉浸过任何网络性质的手游，不懂怎么挖坑赚大 R 的钱。只知道打磨那些 demo 中自己认为有趣的地方。所以对于这个项目是否立项，作为公司的决策人是很为难的。正巧我玩了一年多的 steam ，并在上面已经买了几十个游戏，交了很多好友。让我感觉到，其实，制作精良的单机游戏也是有机会收回开发成本的。游戏玩家始终还是一个小群体，只是网络游戏的热潮把所谓游戏玩家的群体放大了。但原来玩单机游戏的那一部分小众依然存在，且只要游戏质量没问题，为游戏买单的人依旧在那里。所以，我说服了公司的管理层，放任这两个同学继续做下去，公司依旧给他们开工资，可以全职做自己想做的游戏，他们只需要把游戏做的自己喜欢，不用考虑怎么收费的问题。到时候，我们争取上 steam 平台，不卖 IAP ...继续阅读 (68)

从周末开始, 我一直在忙一个想法。我希望给 skynet 中的 lua 服务定制一个内存分配器。倒不是为了提升性能。如果可以单独为每个 lua vm 配置一个内存分配器，自己调用 mmap 映射虚拟内存，就可以为独立的服务制作快照了。这样可以随时 fork 出子进程，只保留关心的 vm 的内存快照。主要可以有三个用途：可以在快照上做序列化，并把结果返还父进程。通常做序列化有一定的时间代价，如果想定期保存的话，这个代码很可能导致服务暂停。可以利用快照监控检查泄露。定期做快照相比较，就能找到累积的对象。我曾经做过这样的工具。可以在镜像上对快照做一些调试工作而不会影响主进程。为什么为每个虚拟机单独配备分配器是必要的呢？因为如果对 skynet 整个进程 fork 做出内存快照的话，当所有虚拟机共用一套内存池，很难单独把不感兴趣的内存 unmap 掉。而子进程的内存页是 COW 机制的，一旦子进程工作时间过长，会导致整体内存开销非常大。因为 lua 本身就可以为虚拟机定制分配器，所以比较容易给出一个实现。事实上我花了半天时间就动手完成了，随后花的更多的精力是从已有项目的线上数据里采集真实的分配器工作流程的 log 用来对新写的分配器做测试。让已有项目的分配器加上 log ，逐条记录每个 vm 分配器工作时的分配释放操作在临时文件中，再写一个脚本分析这些 log 就可以还原出内存分配器真实的 ...继续阅读 (93)

最近玩 Rogue Like 比较多。似乎好多游戏都被贴了 Rogue Like 的标签，在 steam 上，像盗贼遗产、以撒这些也被归到 Rogue Like 里去了，但我隐隐觉得它们还不应该被算到经典的 Rogue Like 里去。如果从字面上理解，Rogue Like 似乎又特指界面像 Rogue 的游戏，也就是字符界面，海量的键盘快捷键控制，那么矮人要塞也算一标准的 Rogue Like 。可是 DF 的冒险模式之外的部分又似乎和印象中的 Rogue Like 不同。另外，还有把一些轻量游戏改贴了 Rogue Lite 的标签。玩起来有点像 Rogue Like 细玩又有些差别。今天在 google 上乱逛的时候，发现了这个Berlin Interpretation，觉得很涨知识，摘录如下：作为 Rogue Like 的主要特性，通常有：随机环境生成：游戏世界每次都是随机生成的，这样可以提高重复可玩性。物品、怪物等可以是固定的，但摆放的位置随机。同时可以有一部分固定的内容（谜题，特定的关卡，剧情等）。永久死亡：第一次建角色一般完成不了游戏。死了之后从一级开始。保存游戏只供以后继续，不能靠读档来重来。所以需要随机环境这点来让重来的过程更好玩而不是折磨。回合制：每个指令都对应一个动作。游戏对时间不敏感，你可以随便花多少时间来决定下一步做什么。走格子：世界是由格子划分，怪物和玩 ...继续阅读 (62)

虽然网络游戏假借游戏之名占据着主流之道，其实游戏玩家从来都只是个小众群体。好在靠着网络的力量，小众群体也能找到同好。steam就是这么一个神奇的平台，他的贡献不仅在于改变了（中国）玩家的（盗版）消费习惯，更重要的是提供了一个良性的游戏评价平台，让好游戏可以被玩家认可并促使开发者开发出更好的作品。我在 steam 上的一大乐趣就是翻阅引起我的兴趣的游戏的玩家评测。先从差评看起，了解为什么不被人推荐；再去阅读好评，理解游戏的设计点。在用户生态上，steam 的评测比 ios 的好了不只一个层次。绝大多数情况下，steam 用户的眼光非常犀利。几乎不会有滥游戏被捧上天，也不会有好游戏埋没。至于某些专门迎合更小众群体的偏门游戏，只要制作的好，也不会被误解。因为非该类游戏的用户根本不会购买它，也就不会写评测了。所以，越小众的游戏，好评率越高。如果被差评，几乎都是制作上有问题不太值得一玩的。曾经我几乎不会去玩好评率低于 80% 的游戏以避免浪费自己的精力，但随着深入了解 steam 社区，尤其是顺着我喜欢的一些评测文章去追述那些玩家的足迹，我发现了另一些被埋没的好游戏。Rogue's Tale就是这样一款被严重低评的好游戏。在写这篇 blog 的时候，它的总评测数量是 200 ，其中只有 129 篇好评，好评率 64% 。对于 steam 上发行的游戏来说，这个成绩几乎把游戏判了死刑。当我把这 ...继续阅读 (63)

前两天成功用 mptcp 搭建好出国上 github 的快速通道后，在想如何方便的无缝使用。如果不使用 vpn 的话，就无法用路由规则来把流量倒向隧道。当然修改内部 dns 的 github 域名解析是可以的，但终归不是很舒服。SA 试了一下用PeerVPN搭 vpn tunnel ，工作倒是正常，但是 mptcp 跑在隧道上等于是白费了。PeerVPN 是用 UDP 通讯的，实际上只走了单条路径，如果再在上面跑 mptcp 等于是自欺欺人。所以也曾经考虑过使用基于 TCP 连接的 VPN ，比如 openVPN 。在 SA 尝试做配置的时候，我突然有了个想法。既然 PeerVPN 是开源的，何不修改一下实现，让它支持多个 ip 间建立多条路径的通道呢。读了一下代码发现，其实在 linux 下实现 vpn 是如此简单。linux 已经负责实现了 tun/tap 设备，可以帮你把 ip 层的流量（或以太网层）倒入一个虚拟设备。我们要做的仅仅是处理一下互联网上的通道转发而已。google 了一下多路径的 vpn 方案，发现有这个想法的人太多了。比如Multipath-VPN就是，不过几百行 perl 代码 。PeerVPN 虽然也不复杂，但就我需要的应用来看，大部分功能都是不需要的。所以还不如自己实现一下，应该也就是几百行代码的量吧。如果在 IP 层做流量转发，UDP 肯定是最合适的。 ...继续阅读 (101)

从去年开始，我们的工作项目逐步迁往 github 的私有仓库里。github 太好用了，自己搭建的 git 平台完全比不上。可是购买企业版本自己架服务器成本又太高（平均一个人一年要 250 刀），而我们项目并不多（只是人多）购买私有仓库绝对够用了，唯一的缺点就是 github 没有在国内开展业务，服务器都在境外，速度很慢。之前我们无论是电信还是联通线路，从 github 上 clone 项目的速度一直没有超过 200KB/s ，而我们租用的国际线路本身带宽又很低（因为单价太高，所以只做部分翻墙用）。而且连接还不太稳定，有一定的丢包率。考虑到我们办公室租有多条不同运营商的宽带，所以最近在考虑怎么把这些资源整合在一起使用。带宽的瓶颈显然是在墙上，所以只要提高过墙的带宽就可以了。我在linode 机器上做了测试，从 linode 美国机房 clone github 仓库的速度轻易可以达到 8MB/s 。一开始我的念头是自己写一个支持多条 TCP 连接协作的 tunnel 程序。后来转念一想，MPTCP 不就是干这个用的么？去年的时候玩过一阵 MPTCP，这次和我们爱折腾的 SA 同学们一起再试试。公司曾购买过一个备用翻墙的 linode vps ，不过是很早装的系统，内核不支持mptcp，所以需要先升级。要做的准备工作还包括添加办公室网关上的的路由规则，在内网一个 IP 可以看到所有的出 ...继续阅读 (75)

今天有人转了个知乎上的帖子给我看：Lua 5.3为何很慢？该不该升级？。首先，我不认为 10% 的性能差异能够称的上很大，和 10% 的性能下降相比，程序更清晰稳定、功能更完备（不是指功能多，而是指对各种边界条件处理的更好）要重要的多。毕竟，让 CPU 提升 10% 的性能很容易。其次，在实际项目中，和简单的测试脚本不同，我很难观察到 10% 的差异。（我们的服务器用过 lua 5.2 和 lua 5.3 两个版本，很难从线上压力上感知到性能差别）。如果你真的用那些简单的测试脚本做一个比较，lua 5.1 比它的前一个版本 lua 5.0 要慢得多。差别或许比 lua 5.1 到 5.3 还要大。而为什么很少人关心这个，去用回 5.0 呢？说到底还是因为 luajit 导致的 lua 社区的分裂，让 lua 5.1 这个中间版本变成了另一个 lua 而已。我的硬盘上一直留有从 lua 4.0 开始几乎每个 lua 小版本的源代码副本。而近十年来，一直都在跟进 lua 的源码变迁，所以我对 lua 的每次修改都或多或少有一些印象。下面谈谈我对这个新版本越来越慢的一点个人看法吧。这写这篇 blog 前，我花了一天做了大量的测试对比工作。包括做profile ，编译出汇编逐行对比，阅读版本间的 diff 等等。因为不是写 paper ，懒得把这些工作整理在 blog 里了。主要写写结论。 ...继续阅读 (65)

这是去年在 skynet mailling list 里讨论过的一个话题：skyent中socket中使用共享指针的方式是否有价值？，今天 review 代码的时候又看到，觉得应该在 blog 记录一下。简单说就是，当从 skynet 向外部发送相同内容的数据包时，虽然依旧需要一个个包的发送（除非在局域网做 UDP 组播），但在某些特定需求下，复制多份相同的数据包 buffer 是个不必要的开销。尤其是在上面的帖子中提到的音视频广播的场合，几乎所有的业务都是在向 IO 写同样的数据。所以当时我在考虑后，给 skynet 的 socket 层增加了一个接口，供用户定义共享 buffer ，可以自己在待发送 buffer 对象中自己增加引用计数。考虑到接口向前兼容，这个用户自定义 buffer 对象的方法要求用户在调用 socket send 时，将 size 设置为 -1 ，以便和 raw 指针区分。https://github.com/cloudwu/skynet/blob/master/skynet-src/socket_server.h#L56-L63这样，通过从 C 层面的定制，用户就可以自己实现共享指针了。skynet 的 socket 层会正确的从共享对象里取得指针、取得数据块的大小、以及在使用完毕后释放它。我没有给出更多的用法范例、也没有给出 lua 封装接口，所以这 ...继续阅读 (75)

昨天看到一个好玩的项目https://github.com/nagadomi/waifu2x可以将卡通图片高质量的放大到 2x ，比直接用普通过滤器放大效果好的多。我试了将那张小的卡通妹子不断迭代放大到 8 倍，效果依然是很不错的。公司的程序群里，有同学提出，能不能把算法提取出来，用来做游戏资源图片的压缩。针对卡通类的图片，可以用很小的文件保存，在加载或安装时放大。我觉得有点意思，就做了一些研究。这个放大算法是基于深度学习训练出的一组数据做过滤器的。提取出来做一个不依赖 cuda 的 CPU 实现也不是不可以。不过我在阅读代码时发现了一个有趣的东西先做一下记录。和原始论文不同，这个开源项目是针对卡通图片的。除了他用卡通图片做训练外，我注意到另一个细节。那就是这段程序是先将 RGB 图片转换为 YUV 格式，然后只对 Y 部分做了处理。而 UV 部分都是简单的将值复制了 4 份，也就是说在放大过程中，并没有对 UV 做特别处理。这可能是因为卡通图片一般都是大色块，对色度变化不敏感吧。那么，如果我们将 RGB 图片直接转换为 YUV420 的格式，是不是就可以直接将图片压缩到原来的 50% 呢？我用 imagemagick 对我们的游戏资源做了一下试验，发现转换为 YUV420 再转换回来后，人眼基本分辨不出差别。而 YUV420 到 RGB 的转换是非常容易的（甚至可以直接在 sh ...继续阅读 (57)

Lua 作为一门嵌入式语言，提供了完备的 C API 供 Lua 代码和宿主程序交互，当然，宿主语言最好是 C 或 C++ 。如果是其它语言，比如最近两年流行的在 mono 环境嵌入 Lua 另当别论。正确将 Lua 嵌入是不太容易做对的事情，很多刚接触 Lua 的人都容易犯错误。好在做这种语言桥接工作都是项目开始阶段的设计者做的，不必人人学会，所以只要有熟悉 Lua 的人来搞，犯错误的危害不会太大。而且即使做的有问题，日后修改也比较容易。这篇 blog 主要就是谈谈，最容易做错的位置，和一些正确（但看起来麻烦）的实现方法。最容易忽略的是 Lua 中 error 的处理。Lua 中叫 error ，再其它语言中叫 exception ，后面姑且全部称为异常吧。如果你认真读过Lua 的手册。 就会发现，在所有 C API 那里，都注明了这个 API 是否会抛出异常。比方说lua_tostring就标注的是[-0, +1, e]，有可能抛出异常（是不是和你的直觉不同？）；但lua_pushlightuserdata则不会。Lua 的异常应该由lua_pcall或lua_resume来捕获，所以当你调用 C API 的时候，应该确保在 C 的调用层次上，处于某次lua_pcall或lua_resume中。所以，即使是常见的创建 Lua 虚拟机的简单几行代码，都有可能写错。比如：lua_S ...继续阅读 (60)

sproto 由于主要供 lua 使用，是不能在协议定义中描述缺省值的。所有不编码的字段都呈现为 lua 中的 nil 。注：这里还有个实现上的小问题。如果一个数组为空，也会呈现为 nil 而不是空表，所以应当注意处理。我最近给 sproto 增加了一个新的 api ，可以为一类消息生成一个全部为缺省值的 table 。这样，使用者就可以方便把这个 table 作为别的 table 的 metatable 中的 index 方法了。相当于实现了原来在 protobuf 中的缺省值的特性。只不过，缺省值不能主动定义。所有的 integer 缺省为 0 、boolean 缺省为 false 、string 缺省为空串、子类型为空表，并附加有一项__type为子类型的名字。无数据的数组也缺省为一个空表。使用方法为：sproto:default( typename )给出消息类型名，就可以返回一个全部填有缺省项的表。你也可以用它来取得一类消息中有哪些项。这个 api 也可以用来取协议对应的消息类型，用法是sproto:default(protoname, "REQUEST" 或 "RESPONSE")第二个参数必须为 "REQUEST" 用来取对应协议的请求类型；或是 "RESPONSE" 来取对应协议的回应消息。如果对应消息并不存在（sproto 运行协议不定义请求消息类型或回应消息类型 ...继续阅读 (79)

写这个东西的起源是，前段时间我们的平台组面试了一个同学，他最近一个作品叫做luajit.io。面试完了后，他专门找我聊了几个小时他的这个项目。他的核心想法是基于 luajit 做一个 web server ，和ngx_lua类似，但撇开 nginx 。当时他给我抱怨了许多 luajit 的问题，但是基于性能考虑又不想放弃 luajit 而转用 lua 。我当时的建议是，不要把 lua/luajit 作为嵌入语言而自己写 host 程序，而是想办法做成供 lua 使用的库。这样发展的余地要大很多，也就不必局限于用户使用 lua 还是 luajit 了。没有这么做有很多原因是设计一个库比设计一个 host 程序要麻烦的多，不过麻烦归麻烦，其实还是可以做一下的，所以我就自己动手试了一下。Lua 的多任务库有很多，有兴趣的同学可以参考一下 lua user wiki。一般有几种做法：要么不使用操作系统的线程，只用 lua 本身的 coroutine 来模拟多任务。用 lua 写一个调度器即可。由于 lua 目前允许从 debug hook 中 yield （但暂时需要用 C 来实现 hook），所以甚至你可以实现一个抢占式的调度器；另一种流行的做法是在每个 os thread 里都开启一个独立的 lua vm ，然后用消息通讯的方式协作。大多数库实现出来都是为了解决类似 web 服务这种 ...继续阅读 (56)

最近，我们的合作方 陌陌 带了他们的一个 CP 到我们公司咨询一下 skynet 做 mmo 游戏项目中遇到的一些问题。因为他们即将上线一款 MMO ，在压力测试环节暴露了许多问题。虽然经过我们的分析，有很多问题出在他们的压力测试程序本身编写的 bug ，但同时也暴露出服务器的设计问题。核心问题是，他们在实现 mmo 服务器时，虽然使用了 skynet 框架，但却把所有的业务逻辑都放在了同一个 lua 服务中，也就是一切都运行在一个 lua states 里。这样，几乎就没能利用上 skynet 原本想提供的东西。压力是一定存在的。我花了一下午探讨了应该如何设计一个 MMO 的服务器。下面记录一下：业务的拆分：我认为业务拆分的原则是数据的交互频率。如果数据相互独立，那么就应该用独立的服务去处理；如果交互密切，就不要拆分它们。尽量不让一个服务承担太多热数据的处理，而冷数据或不需要高频响应的数据处理则可以堆积在一起。例如：在 MMO 游戏中，玩家身上的背包管理，基本上只和玩家相关，那么处理背包的逻辑就可以放在玩家的 agent 中处理。即使背包中的物品的操作会影响到其他人或场景，也应该由 agent 和外部交互。对于拍卖行、玩家摆摊等这些，提取出来放在一个或几个交易服务中去完成是没有问题的，但应该避免和场景服务合在一起。虽然拍卖行和摆摊的入口看起来放在场景里，但那仅仅是外在表现，玩家从 ...继续阅读 (70)

sproto是我自己设计, 用在我们新项目中取代过去用到的 google protocol buffers 的东西。为什么不用 protobuf ? 这个问题我有足够的发言权。在 lua 语言为主的项目中，sproto 更合适。google 官方并没有给 protobuf 加入 lua 支持。现在在网上流传的 protobuf lua 方案，被人用的最多的两种，一个是pbc的 lua binding ，另一个是protoc-gen-lua。前者是我在开发维护，并使用了多年；后者是在我过去的项目中，项目中的同事因为需要而开发的。另外，在我的项目的副产品中，还有开源的 protobuffer 的 as3 库以及 erlang 库，都有许多用户。所以，我相信我对 protobuf 有足够长时间的使用经验以及对它有足够的了解。这也是放弃 protobuf 而转向自己设计的 sproto 的底气所在。在这一篇 blog 中，不想讨论 protobuf 的优劣，只谈谈 sproto 中如何使用 rpc 的 api 。这是 sproto 的 api 文档中没有写明，而很多想用它的同学问起的问题。对于 request/response 的 RPC 方案，除了消息本身打包外，还有两个重要的信息需要传输。它们分别是请求的类型以及请求的 session 。不要把请求的类型和消息的类型混为一谈。因为不同 ...继续阅读 (83)

作为一个 X-COM 老系列的爱好者（1994 年开始一直玩了 3 年），新的官方重制版是满足不了我的。Xenonauts作为原作的精神继承者，我很喜欢。本来这个游戏上手了以后是不太依赖文字的，只是可惜了它写的不错的文案。我在网上搜了一下汉化包，几乎都是机器翻译的，读那个真不如读英文啊。游戏的官方没有能力做中文化，但是在官方论坛提供了翻译的指引。我按指引用文泉驿制作了游戏用的字体文件，发现游戏引擎本身对中文支持是没有什么问题的，差的只是文字翻译了。但是这个游戏文字量极大，而且不太容易翻译。我在 github 上创建了一个项目，希望可以集众人之力来完成这个大工程。项目的地址在https://github.com/cloudwu/xenonauts。我在百度贴吧、新浪微博、和 steam 动态上分别发了信息的一天后，居然真有志愿者了。我的想法是这样的，我们先从最难的，也是最有价值的游戏内百科开始翻译。如果顺利再继续界面、向导等部分。原始文件是单个大的 xml 文件，很不利于协作。所以我昨天写了个 lua 脚本把它按条目拆分好了。也有脚本可以合并成最终的文件。ps. 在 github 上协作翻译还是满有意思的。我认为这是一个非常好的协同创作平台，可以专心做校对工作。如果以后游戏策划可以用 md 或 adoc 格式直接写策划案就好了。也就可以搬到 github 上来供大家针对性的讨论了。如 ...继续阅读 (50)

skynet 中使用了一个 hash 表结构来保存服务和 32bit 数字地址的映射关系。一个 skynet 的服务，其实是一个 C 对象。在有沙盒的系统中，尤其是并行构架，我们很少直接用 C 对象指针来标识一个 C 对象，而是采用数字 id 。用数字做 handle 可以让系统更健壮，更容易校验一个对象是否还有效，还可以减少悬空指针，多次释放对象等潜在问题。比如，操作系统为了把用户程序隔离在用户态，像文件对象就是用数字 id 的形式交给用户程序去用的。和操作系统通常管理文件句柄的方式不同，skynet 尽量不复用曾经用过的 id 。这样，当你持有了一个已经不存在的 id ，不太会误当作某个新的对象。（操作系统的文件 handle 很容易造成这样的问题：你记住了一个文件，在别的流程中关闭了它，然后又打开了新文件，结果复用了过去的 handle ，导致你操作了错误的文件。很多年前，我就在自己的线上产品中碰到过这样的 bug。）但是，一旦尽量不复用 id 。用简单的数组来做映射就很难了。必须使用 hash 表来保证映射效率。在 skynet 中我是这样做的：每次分配新的 id 时，首先递增上次分配出去的 id （允许回绕，但会跳过 0 。0 被当成无效 id ）。然后检查 hash 表中对应的 slot 是否有冲突，若有冲突就继续递增。如果 hash 表的池不够用了，则成倍扩大池，并将 ...继续阅读 (53)

上次提到过抵抗组织：阿瓦隆的辅助工具的一个想法。主要是用手机帮助大家减少天黑请闭眼环节的繁琐工作。参加游戏的人只需要看一眼手机，就可以了解游戏局面。这样就不需要额外的主持人不停的叫大家闭眼，某某睁眼确认等等了。另外，也可以简化投票任务这些环节（如果是杀人，那就是确认杀掉谁，指认谁等过程）。一旦去掉了额外的道具，我们就不再需要桌子来玩。可以方便的在饭桌上打发时间了。我在 github 上创建了一个项目。初步的计划是做成一个 web 网站，当然以后改成手机 app 也可以（可以只需要一个 app 做 host，其他玩家还是继续用浏览器访问它，这样就不依赖互联网连接了）。因为我几乎没有 web 开发的经验，所以之搭了个简单的框架，剩余的部分是同事参与来做的。目前之完成了进入房间分配身份的部分，进度比较慢。如果能有经验的同学加入会好一些 :)btw, 我是基于 skynet 开发的。没有什么特别原因，就是因为我之前没做过 web 开发，什么 web 框架都没用过，skynet 比较熟而已。目前这个也谈不上什么特别的设计，目前是怎么简单怎么来。如果要把 skynet 发展成一个可以用的通用 web 框架，我也没经验去想应该怎么搞，所以千万不要把这个当成 skynet 应用的 example :)仓库的地址是https://github.com/ejoy/avalon。如果你觉得这个小项目有点 ...继续阅读 (83)

skynet 的 1.0 版已经发布了 3 个 alpha 版，等稳定以后将发布 beta 版本。最近的问题主要集中在一些我们在老项目中没有使用到的特性上面。尤其是 sproto 这个模块，我希望它将来作为 skynet 推荐的通讯协议，但我们老的项目开始的比 sproto 的项目早，所以早期项目全部使用的是 google protocol buffers （以及我自己做的实现）。 随着新项目的开展，我们公司内部开始大面积使用 sproto ，也就发现了一些 bug ，在最近集中修复。由于 skynet 使用多 lua VM 结构，为了不在每个 VM 里重复加载 sproto 协议，最近增加了 sproto 协议对象的共享。这个作为未写入 sproto 文档的特性提供，当然也不影响 sproto 在其它领域的使用。不过加这个特性比较匆忙，第一次提交时在 gc 方面遗留了一个 bug ，有可能导致多个 VM 重复释放 C 对象，问题已经在仓库最新的提交中修复。另一个为了 skynet 的应用而特别加上的特性是让 sproto 的 decode 可以接收指针（lightuserdata）。固然只接受 string 会让实现更稳固一些，不过在 skynet 里很多地方 string 和 lightuserdata + size 是通用的，所以就顺带支持了。这样可以减少一次内存拷贝。根据使 ...继续阅读 (75)

昨天下午约了一帮同事去密室，由于在最后 40 秒成功破关，大家都很兴奋，决定再换个地方欢乐一下，结果就在地图上找了家附近的桌游店。一开始有 8 个人, 我知道这么多人想开桌游实在没有什么好的选择。玩了两局赛马后又来了三个人。一开始，我实在不想再玩 bluffing game 了。无论是狼人或三国杀，还是抵抗组织，都在三年前玩伤了（开桌游店的日子里，长达半年的时间，每周两个晚上抵抗组织）。这时发现桌游店里有一盒阿瓦隆。一直听说抵抗组织出了这么一个扩充并且口碑非常的好（bgg 上 party game 分类第一），所以饶有兴趣的读了一下规则书。的确有那么一点意思，就组织大家开了几局。正好 11 个人，我可以做主持人。（当然抵抗组织和杀人狼人不同，玩熟了后，完全不需要额外的主持人的）对没玩过抵抗组织的同学来说，我有必要简单介绍一下抵抗组织的规则。熟悉规则的同学可以跳过这一段。简单说就是个不死人的杀人游戏。和所有 bluffing game 一样，由游戏规则决定，将一些线索隐藏在游戏者之间，鼓励玩家制造（和推理识破）谎言来达成胜利目标。和杀人游戏不一样，它解决的重大问题是：不会在整局游戏结束前，有人提前退场。就这一点来说，我偏爱抵抗组织的规则越胜过杀人（狼人)。而且游戏过程中没有黑夜杀人环节，也就不需要额外的主持人了。（当然杀人游戏有个生推变种也不需要）抵抗组织游戏人数 5 到 10 人， ...继续阅读 (76)

花了两天给sproto增加了 unordered map 的支持。问题是这样的：sproto 支持数组，但很多情况下，业务处理中，我们并不用数组来保存大量的相同类型的结构数据。因为那样不方便检索。比如你要配置若干地图表、NPC 表等等的信息，固然可以用 sproto 的 array 来保存。但是在运行时，你更希望用定义好的 id 来检索它们。如果 sproto 不支持 unordered map 的话，你就需要在 decode 之后，对 array table 做一次遍历，用一张新表来建立索引。google protocal buffers 2 也有这个问题，据说第 3 版要增加 map 用来兼容 json ，这个话题最后再说。为了解决这个问题，最简单的方法是在 sproto 的定义中增加一个特性，允许给 array 定义一个主索引。建议编码器在编解码这个数组的时候，按类型的主索引去处理这张表。比如.Person { name 0 : string id 1 : integer email 2 : string .PhoneNumber { number 0 : string type 1 : integer } phone 3 : *PhoneNumber } .AddressBook { ...继续阅读 (62)

在 skynet 中，有一个叫 monitor 的内部模块，它会监测是否有服务可能陷入了死循环。工作原理是这样的：每次处理一个服务的一个消息时，都会在一个和服务相关的全局变量处自增 1 。而 monitor 是一个独立线程，它每隔一小段时间（5 秒左右）都检测一下所有的工作线程，看有没有长期没有自增的，若有就认为其正在处理的消息可能陷入死循环了。而发现这种异常情况后，skynet 能做的也仅仅是输出一行 log 。它无法从外部中断消息处理过程，而死循环的服务，将永久占据一个核心，让系统整体性能下降。采用 skynet 的 kill 指令是无法杀掉死循环的服务的。当服务用 lua 编写时，我们则有可能做多一点工作。对于正统的 lua 程序，我们可以给正在运行的 coroutine 加上一个 debug hook 。在 debug hook 里，则可以检查有没有外部通知说需要中断运行。由于 skynet 的 lua 服务都由一个 coroutine 的调度器管理，的确可以作到为每个请求都加上这个 debug hook 。但问题是，加上 debug hook 后，对正常运行状态的性能影响很大。尤其是 lua 版本的 debug hook ，比直接调用 C API 设置一个 C 版的 debug hook 有更大开销。我认为这个特性对于解决 bug, 尤其是线上解决问题很有帮助，如果能比较 ...继续阅读 (86)