云风的 BLOG

昨天被 D3D12 的一个 bug 坑了一晚上，这个问题很值得一写。

最初是发现 LUID ID3D12Device::GetAdapterLuid() 这个函数有问题。我用 mingw64 编译后的程序，只要调用了一个 api ，d3d12device 设备对象的虚函数表就被破坏掉了。下一次对这个设备的任何 api 调用都会 crash 掉。

由于这个函数的实现在 d3d12.dll 中，是没有源码的，所以只能用 gdb 调试了一下。发现了一个问题：这个 api 的返回值是 LUID ，它是一个结构体。C/C++ 函数返回结构体是没有统一的调用规范的，按道理 COM 的实现应该避免设计这种 API 。

按 COM 的规定，所有 API 必须返回 HRESULT ，只有少量例外可以返回 ULONG 整数。其实之前的 D3D 版本在设计类似 API 的时候都符合了这个约定，例如 D3D9 就有一个类似的 API ：

HRESULT GetAdapterLUID( [in] UINT Adapter, [in] LUID *pLUID )

阅读全文 "Direct3D12 的接口设计 bug " »

云风 提交于 02:03 PM | 固定链接 | 留言 (1)

skynet 的用户中，问的比较多的一个问题是，为什么我改了系统时间对 skynet 却没有生效？继续追问发现，有这个需求的人大多是想实现一个日程表，到某个特定时间触发特定的任务，修改系统时间是为了测试。

不得不说，通过修改系统时间来测试是个直接、却很糟糕的主意。skynet 的定时器也不依赖系统时间驱动，修改系统时间自然也不会生效。

日程服务是个普遍的需求。在国内网游里，你要不做什么节日任务、每周副本，基本不可能上线。这篇 blog 就谈谈这类需求应该在 skynet 中如何实现。

阅读全文 "日程表服务" »

云风 提交于 03:27 PM | 固定链接 | 留言 (8)

前段时间有一个友商来了一个技术团队到我公司交流，主要是想探讨一下他们即将上线的一款 MMORPG 游戏在内部测试中发现的网络卡顿问题是否有好的解决手段。

经过了解，卡顿主要是在压力测试中表现出的网络消息流量过大造成的，又没有找到合适的方案减少流量。

关于 MMORPG 的网络部分的设计，我之前写过很多 blog 。最近两年写过这样两篇：MMORPG 客户端的网络消息框架 、如何只基于请求回应模式实现 MMO 级别的场景服务 。

昨天，我们自己的一个 MMORPG 项目中发生一个小 bug ，就这个 bug 我们做了一些讨论。我想借这个问题展开，在一个抽象层面谈谈我觉得 MMORPG 的网络同步应该怎样做。

阅读全文 "MMORPG 的同步设计" »

云风 提交于 04:12 PM | 固定链接 | 留言 (9)

昨天我们一个项目发现了一处死循环的 bug ，经过一整晚的排查，终于确认是 lua 5.3.4 的问题。

起因是最近项目中接入了我前段时间写的一个库，用来给客户端加载大量配置表格数据 。它的原理是将数据表先转换为 C 结构，放在一块连续内存里。在运行时，可以根据需要提取出其中用到的部分加载都虚拟机中。这样做可以极大的提高加载速度。项目在用的时候还做了一点点小修改，把数据表都设置成 weaktable ，可以让暂时不用的数据项可以回收掉。

正式后面这个小修改触发了 bug 。

阅读全文 "Lua 5.3.4 的一个 bug" »

云风 提交于 09:33 AM | 固定链接 | 留言 (6)

现在的 IM 在设计上是基于会话的，多个人可以组成一个会话，相当于一个聊天室，当一个人加入到一个会话后，就可以看到从加入开始之后这个聊天室里所有参与人的发言。有的 IM 会把两人对话也抽象成同一个东西，也可能出于优化的考虑把双人对话特殊处理。

所以，这些 IM 在操作界面上会有一个会话列表：表现出来会是联系人名单、聊天群列表等等。选中会话列表中的项目，进入会话查看聊天记录、发言，就是这类 IM 的使用逻辑。

我认为，这种对即时通讯的抽象方式，其实是不适合办公环境的。和日常个人社交环境不同，办公群体其实是一个相对关系密切的团体，我们通常不会拉黑一个同事不让他给你发消息，也不会拒收公司发的通告，也不会因为一个同事平常不和你打交道就拒绝建立联系。项目组里的讨论，也未见得是多么保密的事情，需要防止隔壁组的同事旁听。你也很少会在办公 IM 上和妹子私聊谈人生理想。

我们这几年使用腾讯的 RTX 作为公司办公使用，我就感受到了太多这类设计缺陷。比如，有同事找我有事，我忽略了他的私聊信息；找人一般在对方活跃的项目群组里吼；程序群沦为了日常扯淡的位置，常常同时讨论着不同的问题，线索及其混乱。“群”这个设计，我在很多年前就思考过 ，我一直觉得需要在根本上换个角度看待社交聊天的需求。

阅读全文 "基于办公的 IM 的基础设计" »

云风 提交于 03:45 PM | 固定链接 | 留言 (18)

昨天阿楠发现了项目中的一个 bug ，是因为浮点运算的前后不一致导致的。明明是完全相同的 C 代码，参数也严格一致，但是计算出了不相同的结果。我对这个现象非常感兴趣，仔细研究了一下成因。

原始代码比较繁杂。在弄清楚原理后，我简化了出问题的代码，重现了这个问题：

static void
foo(float x) {
    float xx = x * 0.01f;
    printf("%d\n", (int)(x * 0.01f));
    printf("%d\n", (int)xx);
}

int
main() {
    foo(2000.0f);
    return 0;
}

使用 gcc 4.9.2 ，强制使用 x87 浮点运算编译运行，你会发现令人诧异的结果。

gcc a.c -mfpmath=387

19
20

前一次的输出是 19 ，后一次是 20 。

阅读全文 "浮点运算潜在的结果不一致问题" »

云风 提交于 10:31 AM | 固定链接 | 留言 (15)

虽然以现在的加密技术，主要选择的加密算法没问题，在很长一段时间都不太用担心监听通讯的人解密获得明文。但是针对特定的加密通讯协议，还是很可能找到方法找到某种模式。这个模式不能转换为明文，但可以猜测出你是否在使用特定协议。

另外，无论你怎么加密通讯，访问特定服务流量的时间特征也可能泄露你的秘密：用什么节奏通讯，每个 ip 包多大，这些都是可供匹配的特征。

我认为，大多数情况下，通讯的稳定性是大于带宽的需求的。那么，采用本文这种方法应该能去掉上面这些流量特征。

阅读全文 "防止深度包检测的一个方法" »

云风 提交于 10:02 AM | 固定链接 | 留言 (13)