现在很多人一提高性能后端开发，就总会想起 EPoll 来。其实一个成熟的高性能服务器，epoll相关的代码，不到万分之一。
而往往入门服务端的人，都天真的人为：高性能服务端开发 == EPOLL，真好笑，之所以会出现 epoll这种被捧上天的垃圾，明明就是 posix 或者最早版本的 unix/bsd/systemv 的设计考虑不完善。
按今天的眼光反思 posix 和 unix/bsd/systemv 当年的设计，epoll 这种补丁就不应该实现。
异步 reactor 框架应该就只有一个简单而统一的 selector 就足够了，所有系统都相同，提供：
- register: 注册
- unregister：删除
- set：设置
- wait：等待事件
- read：读取事件
- wake：将等待中的 wait 无条件唤醒
别以为这些 poll / epoll / kevent / pollset / devpoll / select / rtsig
是些什么 “高性能服务器” 的 “关键技术”，它们只是一个 API，而且是对原有系统 API设计不完善打的补丁，各个内核实现了一套自己的补丁方式，它们的存在，见证了服务端技术碎片化的遗憾结果。
之所以会有这些乱七八糟的东西，就是早期的 posix / unix/ bsd /systemv 设计不周全，或者不作为留下的恶果。并非什么 “关键技术”。
不用提 windows 的 iocp了，proactor 会来强奸你代码结构，遭到大家唾弃是有原因的。不像 reactor那样优雅，所以 java nio 选择 reactor 是正确的。即便在 reactor 中，epoll 也是一个失败的例子，调用最频繁的 epoll_ctl 的系统占用估计大家都感受过吧，这方面 epoll 真该象 kevent / pollset 学习一下。
实时动作游戏在近年来得到迅猛的发展。而游戏同步问题，成为大家继续解决的核心问题之一。早在 2004年，国内游戏开发还处于慢节奏 RPG满天飞的情况下，我就开始实时动作游戏研究，分别在 2005-2006期间写了一系列相关文章，被好多网站转载：
帧间同步模式：《帧锁定同步算法》（2007）： https://www.skywind.me/blog/archives/131
玩法规避模式：《网络游戏同步法则》（2005）： https://www.skywind.me/blog/archives/112
预测插值模式：《影子跟随算法》（2007）： https://www.skywind.me/blog/archives/1145
如今十年过去，网上越来越多的人开始讨论游戏同步技术了，然而很多文章往往只针对某种特定的游戏情况，而观点又经常以偏概全。很多人并没有真正开发过实时动作游戏，更别说了解同步技术的前世今生了。转载别人的观点并加上自己理解的人很多，实际动过手的人很少。避免给更多人造成无谓的误导，我今天基于先前的实践和对欧美动作游戏，战网游戏，主机游戏（PSN，XBox Live等）网络技术的了解，来对这个问题做一个简单总结：
网速的变化
开发快速动作游戏，首先要对公网的网络质量数据有详细的了解。这里所说到的网速，是指 RTT，数据往返一周的毫秒时间，而非每秒传送多少 KB/s。我写这篇文章是基于我 2005-2006年开发的东西来说的，当时国内公网质量比国外差很多：
上图为 2005-2006年国内的网络环境，某三个省级 IDC的情况采样。当时公网 RTT平均值基本在100ms，120ms左右徘徊。所以我文中引用了很多 100ms。这个情况在2009 年以后已经好了很多（60ms的rtt）。到了2012年以后，公网平均 RTT已经降低到平均 40ms-50ms，省内平均10ms以内了：
上图为 2015年某省级 IDC的全国延迟情况，如若全国多布点以及区别电信联通的话，平均延迟能控制在20ms以内，延迟基本接近国外水平（当然带宽还差很多），比我当年文章中提到的网络情况好了不少。
Read more…
《游戏服务端发展史》转载请著名出处：https://www.skywind.me/blog/archives/1301
类型4：第三代游戏服务器 2007
从魔兽世界开始无缝世界地图已经深入人心，比较以往游戏玩家走个几步还需要切换场景，每次切换就要等待 LOADING个几十秒是一件十分破坏游戏体验的事情。于是对于 2005年以后的大型 MMORPG来说，无缝地图已成为一个标准配置。比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了：
Read more…
手游页游和端游，本质上没有区别，区别的是游戏类型：
《游戏服务端架构发展史》转载请著名出处：https://www.skywind.me/blog/archives/1265
类型1：卡牌，跑酷等弱交互服务端
卡牌跑酷类因为交互弱，玩家和玩家之间不需要实时面对面PK，打一下对方的离线数据，计算下排行榜，买卖下道具即可，所以实现往往使用简单的 HTTP服务器：
登录时可以使用非对称加密（RSA, DH），服务器根据客户端uid，当前时间戳还有服务端私钥，计算哈希得到的加密 key 并发送给客户端。之后双方都用 HTTP通信，并用那个key进行RC4加密。客户端收到key和时间戳后保存在内存，用于之后通信，服务端不需要保存 key，因为每次都可以根据客户端传上来的 uid 和 时间戳 以及服务端自己的私钥计算得到。用模仿 TLS的行为，来保证多次 HTTP请求间的客户端身份，并通过时间戳保证同一人两次登录密钥不同。
Read more…
KCP是一个快速可靠协议，能以比 TCP浪费10%-20%的带宽的代价，换取平均延迟降低 30%-40%，且最大延迟降低三倍的传输效果。纯算法实现，并不负责底层协议（如UDP）的收发，需要使用者自己定义下层数据包的发送方式，并以 callback的方式提供给 KCP。连时钟都需要外部传递进来，内部不会有任何一次系统调用。
整个协议只有 ikcp.h, ikcp.c两个源文件，可以方便的集成到用户自己的协议栈中。也许你实现了一个P2P，或者某个基于 UDP的协议，而缺乏一套完善的 ARQ可靠协议实现，那么简单的拷贝这两个文件到现有项目中，稍微编写两行代码，即可使用。
URL：https://github.com/skywind3000/kcp
Read more…
今天参考 ZeroMQ的观点为我们的网络模块增加了一个“订阅模式”，及客户端包头用四字节表示，低24位为长度，高八位为“消息分类”。后端连接网络层的若干“频道”可以根据自己的喜好订阅“分类消息”，那么客户端发送该分类消息到网络层的时候，将会被抄送到订阅过该分类的频道。每个频道还可以订阅若干系统消息，比如连接开始、断开、时钟等等。
我们的服务器自2004年底到现在，一直是网络和逻辑分离在不同的进程（主机）中间，网络模块可以连接多个提供服务的“频道”，只是配合休闲游戏的模型，当前只有一个频道可以和特定玩家进行交互。不过其基于多频道的模型使得这次改进很容易，改了三个小时，又跑了几个小时的测试用例，基本通过。
以后交易，聊天，逻辑等，都可以分布在不同的频道里面同时为玩家提供服务了。
1. 跨平台网络库
2. 异步事件：kevent, iocp, epoll, poll, select封装
3. 内存管理：SlabPlus
4. 可靠协议：类tcp纯协议实现，包括重传机制，窗口管理，流量控制，拥塞处理。
5. 多种工具：缓存池，环状缓存，高性能hashmap等。
代码贴上：
Read more…
Recent Comments