DC3算法

最近做了一个差量更新工具， 实质就是一个Diff工具。这个Diff工具在本地生成一个patch文件。客户端通过网络下载到本地后，根据本地文件和patch文件来生成最新版本文件。 与传统patch不同的是，为了尽可能的减少网络传输，patch文件需要尽可能的小，并且不需要逆向patch(从版a到版本b生成的patch, 版本b使用这个patch可以还原到版本a). 基于以上考虑，我重新设计了一个二进制patch格式，整个patch文件中有两种Action（分别是COPY， INSERT)，大致数据结构如下： [c] struct COPY { ……

开卷有益(UNIX编程艺术篇)

最近《计算机程序设计艺术》看多了，每次写完代码之后，总会习惯估算一下指令级的开销。导致每次写代码都是性能导向，违反了很多设计准则。因此打算重新看一下《UNIX编程艺术》，来拉一下已经严重倾斜的天平。 刚看了二页，又想起一个困扰我多年的问题，而没想到的是这次我似乎想到了解决办法。 在写服务器程序时，将数据持久化到数据库，是一个必不可少的操作。它需要将一个结构体进行打包，然后通过网络发给数据库，数据库再进行，并将操作结果通过网网络返回给应用程序。虽然可以……

谈谈我对数据同步的理解

We性质b和网游最大的不同也许就在于数据同步。 Web的工作流程（这里不包括页游）虽然也有很多变化，但是一般都大致分为三步。 1. 在浏览器输入网址， 浏览器通过HTTP协议请求服务器加载数据，服务器在收到HTTP请求之后，从数据库加载相应的数据（有可能是HTML,JS等一些用于浏览器渲染的数据）并返回给客户端。这一步我称之为查询。 2. 浏览器收到服务器返回的数据之后，将数据渲染并呈现给用户。这一步我称之为渲染。 3. 用户在看到浏览器呈现的内容之后，根据需要去执行不同的操作……

又一个lua调试器

最初，我并没有打算为Silly提供一个lua调试器，因为我本人不是一个重度调试器使用者。在开发期间出bug，看一下代码，打几条log可能比使用调试器会更快的找到问题，尤其是服务端程序，在很多时候其实只有log这一原始工具可以使用。但就我周围的人来推断，应该还是有很多重度调试器使用者。 因此，最终还是计划为Silly增加一个lua调试器作为基本组件存在。但是这个调试器到底以哪种方式提供调试功能，我一直在纠结中。 就我个人而言，我用过至少两种完全不同的调试器，gdb和dtrace（严……

客户端缓存落地方案

先大致描述一下场景，客户端按登陆流程成功登陆后，开始按各个模块加载所需数据，待收到消息返回后cache在内存中，只有当所有模块全部加载完成之后，客户端才算真正登陆成功，这时玩家才可以进行各种操作。在玩家操作过程中，客户端不断与服务器进行消息交互，并始终与服务器数据保持一致（这里是指状态一致，不是指所有数据全部一致，服务端存储的数据与客户端所需要的数据并不完全相同）。 由于模块过多，每个模块都是分别独立加载，因此从用户点击登陆按钮开始到真正可以操作所经……

Paxos算法

大神说，世界上只有一种一致性算法，那就是Paxos。 但是大部分文章或论文的套路都差不多，先说paxos是一个完美的一致性算法，然后就给出证明等等，最后才给出实现步骤。 然而，对于我这个初学者来讲，我更希望先知道这个算法是如何工作的，然后再去研究他们的证明过程。这其实也符合学习的过程，先抛出问题，思考之后，最后看答案印证。然而大神写的Chubby并不开源，而证明过程也很数学化，很难理解在实际执行流程当某一步出现错误时，这个算法是如何保证数据的一致性的。 本文从pax……

HTTP服务器的特点

最近一个月在学习关系性数据库mysql, 顺便看了一下http服务器的编写。写了这么久的游戏服务器,数据库也一直使用nosql。因此在初次尝试使用mysql编写http服务器程序时，产生了强烈的反差。 在使用APP的验证过程中，经常会遇到短信验证码问题。 下面就以‘如何实现短信验证码服务’来对比一下http服务器和游戏服务器（mysql和nosql)解决此类问题的不同之处。主要涉及数据结构定义、优化、及逻辑代码的更新问题。 先来明确一下‘业务流程’，最简单的‘短信验证码服务’至少要提供3个操……

实现了一个AOI模块

在场景服务中，如果有一个人A的行为想要被其他人看得到，就必须将A的数据包进行转发给其他人。 最KISS的办法，就是直接把A的数据包直接在场景服务内组播。 但是在一个场景服务中可能有成百上千个人，如果直接在服务进程内进行广播，数据流量会大到一个很夸张的地步，至少以目前的网速来讲是不现实的。 因此，往往场景服务都为人物设计一个视野半径，即只将数据包转发给在我视野内的人，这样可以极大的降低数据的转发流量。 而AOI(Area Of Interest)正这样一个可以帮我们快速确定视野……

一个高可伸缩的游戏服务器架构

设计完socket通讯协议后，就面临着服务器架构设计了。我希望他是一个去中心化且具有高可伸缩性的集群架构。 水平扩展是高可伸缩的首要条件，因此，在设计之初就必须考虑好水平扩展考方案。事实上这一部分几乎花了我1整个月的时间来设计，在此期间我重写了3版才总算确定下来我认为可用的方案。 第一版设计方案如下： 将服务器分为3类，分别是GateServer, LoginServer, LogicServer。 GateServer管理客户端链接，数据包的加密、解密、广播、转发等与业务逻辑无关的操作。当压力过大时……

关于网络协议封装的一些新想法

最近业余时间在写一个小游戏。在为客户端封装socket层时头脑一热，有了一些新的想法, 在这里记录一下。 客户端使用的是Unity3d引擎。而在Unity3d中，基础的socket库只提供两种模式，一种是阻塞模式，一种是异步callback模式。 一般都需要基于这两种模式下进一步封装，才可以更方便的使用。 咨询了几个做客户端的并搜了一下，发现大家的惯用手法都是开一个线程去使用socket阻塞去读，然后把读到的数据通过队列传回主线程进行处理。 但是也许是单线程的思维模式已经深入我心了，所以我……