IT牛人博客聚合

这个周末又 想到这个问题, 是由另一个问题引起的.

为了模拟复杂的网络环境，我们在内网安装了模拟环境 。

怪物公司同学周末调试客户端时，修改了自己机器的网关，增加了模拟延迟。奇怪的是，他的客户端在切换网关时并没有断开连接。可延迟也果真发生了。

我和他探讨了一下，觉得这个模拟延迟是单向的。当游戏服务器发送数据包回桌面时，由于服务器和他的桌面机在同一个网段，所以 IP 包被直接发回了。TCP 连接也不因为修改了过去的通路和断开。

当然，这种模拟并不是我们想要的。正确的方法应该是在修改网关（指向延迟模拟机器）的同时，也修改桌面机的 IP ，或是给自己机器绑定两个 IP ，使用模拟环境网段的 IP 来重新建立 TCP 连接。或者在模

查看全文: http://www.udpwork.com/item/7098.html

前段时间谈到了 ringbuffer 在网络通讯中的应用 。有不少朋友写 email 和我探讨其实现细节。

清明节放假，在家闲着无聊，就实现了一个试试。虽然写起来还是挺繁杂的，好在复杂度还在我的可控范围内，基本上也算是完成了。

设想这样一个需求：程序 bind 并listen 一个端口，然后需要处理连接到这个端口上的所有 TCP 连接。当每个连接上要数据过来时，收取这些数据，识别出封包，发送给对应的逻辑层处理。如果数据不完整，则暂时挂起这些数据，直到数据收取完整再行处理。

我写的这个小模块实现了这样一组特性，因为使用了唯一的 ringbuffer 缓存所有的连接，可以保证在程序运行过程中，完全没有额外的内存分配操作。

在编写

查看全文: http://www.udpwork.com/item/7075.html

这是一篇命题作文，源于今天在微薄上的一系列讨（好吧，也可以说是吵架）。其实方案没有太多好坏，就看你信不信这样做能好一些或坏一些。那么，整理成 blog 写出，也就是供大家开拓思路了。

我理解的需求来源于网络服务提供程序的一个普遍场景：一个服务器程序可能会收到多个客户端的网络数据流，在每个数据流上实际上有多个独立的数据包，只有一个数据包接收完整了才能做进一步的处理。如果在一个网络连接上数据包并不完整，就需要暂时缓存住尚未接收完的数据包。

问题是：如何管理这些缓冲区比较简洁明了，且性能高效。

其实这个有许多解决方案，比如为每个网络连接开一个单独的固定长度的 buffer 。或是用 memory pool 等改善内存使用率以及动态内

查看全文: http://www.udpwork.com/item/6775.html

过年了，人都走光了，结果一个人活也干不了。所以我便想找点东西玩玩。

今天想试一下 libev 写点代码。原本在我那台 ubuntu 机器上一点问题都没有，可在 windows 机上用 mingw 编译出来的库一个 backend 都没有，基本不可用。然后网上就有同学推荐我试一下 libuv 。

libuv 是 node.js 作者做的一个封装库，在 unix 环境整合的 libev ，而在 windows 下用 IOCP 另实现了一套。看起来挺满足我的玩儿的需求的。所以就试了一下。

这东西没有文档，暂时没看出来作者有写文档的打算，恐怕他是自己用为主。我 google 了一下，就是 github 上有源代码，.h 文件里有还算比

查看全文: http://www.udpwork.com/item/6731.html

其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。

本来我在 weibo 上闲扯两句，这么简单的方案，本以为大家一看就明白的。没想到还是许多人有疑问。好吧，写篇 blog 来解释一下。

简单说，我们设置几个网关服务器，用动态 DNS 的方式，把并发的订票请求分摊开。类比现实的话，就是把人分流到不同的购票大厅去。每个购票大厅都可以买到所有车次的票。OK ，这一步的负载均衡怎么做我就不详细说了。

每个网关其实最重要的作用就是让订票的用户排队。其实整个系统也只用做排队，关于实际订票怎么操作，就算每个网关后坐一排售票员，在屏幕上看到有人来买票，输入到内部订票系统中出票，然后

查看全文: http://www.udpwork.com/item/6686.html

前几天写的 pbc 初衷就是想可以方便的 binding 到动态语言中去用的。所以今天花了整整一天自己写了个简单的 lua binding 库，就是很自然的工作了。

写完了之后，我很好奇性能怎样，就写了一个非常简单的测试程序测了一下。当然这个测试不说明很多问题，因为测试用的数据实在是太简单了，等明天有空再弄个复杂点的来跑一下吧。我很奇怪，为什么 google 官方的 C++ 版性能这么差。

我的 lua 测试代码大约是这样的：

local protobuf = require "protobuf"

addr = io.open("../../build/addressbook.pb","rb")
buffer = addr:

查看全文: http://www.udpwork.com/item/6526.html

我一直不太满意 google protocol buffers 的默认设计。为每个 message type 生成一大坨 C++ 代码让我很难受。而且官方没有提供 C 版本，第三方的 C 版本 也不让我满意。

这种设计很难让人做动态语言的 binding ，而大多数动态语言往往又没有强类型检查，采用生成代码的方式并没有特别的好处，反而有很大的性能损失（和通常做一个 bingding 库的方式比较）。比如官方的 Python 库，完全可以在运行时，根据协议，把那些函数生成出来，而不必用离线的工具生成代码。

去年的时候我曾经写过一个 lua 版本的库 。为了独立于官方版本，我甚至还用 lpeg 写了一个 .proto 文件的解析器。

查看全文: http://www.udpwork.com/item/6439.html

今天在 greader 上看到这么一篇，用 DNS 隧道实现免费上网。我的思绪猛然回到去年去新西兰度假的日子。

有那么几天，我们在惠灵顿的海边山顶租了个屋子，一切都很舒服，但是不能上网。甚至于附近连 wifi 信号都收不到，想"借用"一下别人的 wifi 热点都不成。我顶着海边的狂风在院子里竖起天线，捕捉着周围微弱的信号，最终未果。然后转战屋里的有线电视。我发现和国内的有线电视一样，机顶盒是接有网线的。也就是说，物理上，存在一条链路接入了互联网。但是我插上电脑后，发现 ip 包根本发不出去。不过，好似有个 DNS 服务是可以用的。

当时也没多想，只是觉得有办法可以利用一下。不过隔天就搬走了，没有深入下去。今天回味一下，感觉的确可

查看全文: http://www.udpwork.com/item/5361.html

最近 Lua 社区非常活跃。6 月 22 日发布了 Lua 5.2.0 (beta-rc2) 。今天(6 月 24 日) 发布了 LuaJIT-2.0.0-beta8 。

虽然 luajit 和 lua 5.2 还有点小矛盾，luajit 没有完全支持 lua 5.2 的迹象。不过，这些对 Lua 社区都是好消息啦。可能对于 lua 用户会有点小纠结，到底是追随官方的 5.2 版呢，还是去用性能更好的 luajit2 。我比较在意性能，暂时先投靠 luajit 了。反正和 5.2 区别也不大。更重要的是，luajit2 提供的 ffi 库相当之好用，极大的减少了我们写 C 库的 lua binding 的负担。从某种角度可以看到另

查看全文: http://www.udpwork.com/item/5347.html

信息加密技术已经很成熟了。不过想把加密信息伪装隐藏在看似明文的信息中的工具我还没有见到。

我的意思是，监听方完全察觉不到有密文在传输的情况下，把加密信息传输给对方。我记得有工具可以在图片中隐藏一些信息，即使图片经过扫描，隐藏在其中的密文信息依然可以读出。

我能想到的方式有好几个。一是在正常的聊天通讯中，通过对语句的语法分析，找到一些常用，却可以同义替换的词，或是常见的由于拼音输入法输入错误的同音字。做有规律的替换。每个替换可以编码 1 bit 的数据进去。换句话说，一个别字相当于 1 ，一个可以错的字写对了，可以编码为 0 。为了让别字不那么多，可以定规则为每句话的固定次序的某个字包含有额外信息等等。这些规则可以扩展开。

也可

查看全文: http://www.udpwork.com/item/5105.html

昨天读到了 Bitcoin 的中文介绍，觉得非常有意思。不过上面这篇文章解释的非常不靠谱，我花了一晚上去Bitcoin的官方网站 仔细研究了一下，总算理解了其原理。感觉非常有启发，尤其是对虚拟货币的流通和发行有许多借鉴意义。今天写这篇 Blog 理一下。

什么是货币呢？货币就是商品(包括服务)交换的媒介。现在我们通行的货币是由有信誉的银行发行的，基本上是由其信誉来担保的。只要用的人都认可，那么我们就可以用它来交易。货币有一定的保值特性，我把我的劳动/服务/所有的商品换成货币后，银行担保我在日后的某一天，我还可以用它交换会差不多等值的东西。这个保证的前提是，银行不会滥发新的货币以及大家都信任这一点。

以前，我们用贵金属做货币。因为

查看全文: http://www.udpwork.com/item/5062.html

今天一个朋友用 qq 邮箱给我发了个 200+ M 的大文件，我无法提取。这让我意识到，在网络上分享大文件也是个比较大的需求。此类服务很多，历史也很悠久（很多网盘也被用户用来解决此问题）。但好用的并不多。

记得 opera 的新版也提供了分享本机文件的功能，可能是墙的原因，在国内也很难用。

我觉得如果为公众提供一个方便的渠道（又尽量压缩成本）来分享自己机器上的文件，或许会有许多用户的。关键在于便捷，功能纯粹。

最简单的方法是让发送文件方在本机架一个 web server ，然后把文件放到 web server 可以管理的文件服务目录中去。这个方案最好实施，对于懂行的同学来说，windows linux 等都提供有 httpd

查看全文: http://www.udpwork.com/item/4390.html

在需要并行化处理数据的时候，采用消息队列通讯的方式来协作，比采用共享状态的方式要好的多。Erlang ，Go 都使用这一手段来让并行任务之间协同工作。

最近读完了 ZeroMQ 的 Guide。写的很不错。前几年一直有做类似的工作，但是自己总结的不好。而 ZeroMQ 把消息通讯方面的模式总结的很不错。

ZeroMQ 并不是一个对 socket 的封装，不能用它去实现已有的网络协议。它有自己的模式，不同于更底层的点对点通讯模式。它有比 tcp 协议更高一级的协议。（当然 ZeroMQ 不一定基于 TCP 协议，它也可以用于进程间和进程内通讯。）它改变了通讯都基于一对一的连接这个假设。

ZeroMQ 把通讯的需求看成四类。其中一

查看全文: http://www.udpwork.com/item/4363.html

把网络游戏服务器分拆成多个进程，分开部署。这种设计的好处是模块自然分离，可以单独设计。分担负荷，可以提高整个系统的承载能力。

缺点在于，网络环境并不那么可靠。跨进程通讯有一定的不可预知性。服务器间通讯往往难以架设调试环境，并很容易把事情搅成一团糨糊。而且正确高效的管理多连接，对程序员来说也是一项挑战。

前些年，我也曾写过好几篇与之相关的设计。这几天在思考一个问题：如果我们要做一个底层通用模块，让后续开发更为方便。到底要解决怎样的需求。这个需求应该是单一且基础的，每个应用都需要的。

正如 TCP 协议解决了互联网上稳定可靠的点对点数据流通讯一样。游戏世界实际需要的是一个稳定可靠的在游戏系统内的点对点通讯需要。

我们可以在一条

查看全文: http://www.udpwork.com/item/2084.html

自从我自己购买了 linode 的 vps 后，我就没再用过免费的 ssh server 翻墙。

今天有同学问起，说 silenceisdefeat 不能用了。我登上去看了一下，在 /etc/ssh/sshd_config 里加了一句

AllowTcpForwarding no

嗯，估计是觉得好多人用它来做 proxy ，流量受不了，关掉了。

如果还想继续用怎么办呢？

试了一下，服务器是允许编译 C 程序的，可是不能运行 :(

但居然装有 python :) 赶紧下了个简单的 http proxy 运行。发现可以正常工作，只是仅限于本地。估计是设了防火墙，从外面不能连接上这个proxy 。

不过问题不大。在自己机器上

查看全文: http://www.udpwork.com/item/1819.html