初始化时间过长

CEGUI在初始化的时候，会便利一个字体中所有的Glyph，并在d_cp_map容器中初始化所有的FontGlyph对象。这个在英文字体下没有什么问题，因为一个字体中大约只有几百Glyph，但是在中文字体中这个值一般是65535个，所以初始化的时间过长。准备废除这个初始化的过程。

CEGUI使用一个bitmap，d_glyphPageLoaded作为一个codepoint有没有载入的标志，在这里废弃这个变量，直接使用d_cp_map容器中有没有对应的FontGlyph对象作为这个codepoint有没有载入的标志。

字体缓冲的贴图占用过多

CEGUI中的字体缓冲有一个算法，就是把字体中的Glyph分页，每个页是256个文字，一旦要渲染一个文字的时候，就把这个文字前后一共256个Glyph都渲染到一张贴图上。对于英文字体来说这样不是问题，一个字体最多渲染5到6张贴图就完事了，而且采用这种策略渲染好的贴图就不需要修改了。但是对于中文字体来说这不是一个好的策略，中文字体中文字个数繁多，而且不是采用使用频率在字体中排列的，你渲染的一个文字的前后255个文字说不定在整个过程中就不会使用得到，如果讨论在极端情况下，一个中文字体一共需要65535/256=256张贴图才可以完整的渲染完，这样我们可怜的显存里面就全部都是文字了，明显不可以接受。

计划使用一个简单的缓冲机制，就是一开始设定好一个字体可以使用多少张缓冲贴图，和每张贴图的尺寸（这里暂定512*512）。这样的策略实现起来比较简单，相对来说修改的代码量也不是很大，缺点是：

1. CEGUI的贴图接口中并没有锁定或修改已存在的贴图内容，需要自己实现。
2. 原始的贴图生成之后不需要修改了，现在需要经常修改，会有一定的效率损失。

其实把我的账户ban掉的原因很简单，就是我的信用卡的资料不对。不知道什么原因，google checkout内部支持的信用卡的国家地区选项里面吧中国剔除了（之前是有的，我肯定）于是我们就只能选用不正确的国家地区：香港。

我是2010-1-19日下的订单，三天之后checkout账户就被ban了，登陆checkout账户之后就提示我进行申述，于是我就准备了他要求的两种资料：

1. 你个人的信息，可以是身份证或者是护照的扫描件，我选择的是护照的扫描件
2. 可以证明你信用卡归属和billing address的信息，我们的billing address本来就是不正确的，所以我扫描了我的招行信用卡的账单和我的信用卡的正面（卡号的前9位遮住）
3. 其他信息

这个其他信息非常重要，我写了一篇很热情洋溢的信，由于我的英文写作很差，所以破费周折，原文如下：

  I’m this credit card’s holder and I have left the correct card information. But the billing address I left was not match my bank billing address. Because there is no option "China" in the combobox when I was filling the billing adress form so I left the address where I was living one year ago when I’m working in HK. But then I moved to mainland China Shanghai.

  Under this special situation I am not able to provide the billing address of HK since I am now living in Shanghai and the bank send the bills to my new address in Shanghai. I sincerely hope you can understand my special situation and reactivate this account,so that I can place order again and ship Nuxus one to my uncle with his HK address.

  Thanks for your time and pls let me know if you want more documents to verify this account.

建议大家不要原文照抄，一定要修改修改。。。。。而且更加重要的事情，人家三天后就回信了，表明，就是要ban你，回信原文如下：

Hello Luyi,
Upon review of your account, it appears that your information corresponds
with a currently unsupported billing country. To view a list of supported
billing countries, check the Location: drop-down menu on the sign-up page.
As a result, your account associated with xxxx@gmail.com has been
suspended and the order(s) have been cancelled.
Any pending and future transactions made with this account will not be
processed.
We understand that order cancellations under these circumstances can be
disappointing. Please know that we look forward to offering more options
in the near future. We regret any inconvenience that this may cause and
appreciate your understanding.

于是我就组织了一份措辞稍稍严厉的信（不容易啊，就我这个英文水平），回复给了这个客服，原文如下：

Hi Mary

I totally understand why my account is suspended. As required, I have proved the credit card ownership, I think there is no reason to suspend my account any longer. You can drop my order, but cannot freeze it forever.
I just got a HSBC credit card which is issued in Hongkong two weeks ago, I think this one could be use in my checkout account. I love my Google account as xxxxxx@gmail.com. Please give me a chance to reactive it with checkout service. I don’t want to register another new account just for the stupid checkout issue.

 

结果放了两个礼拜都没有人理我，所以我估计这个email账号是一个noreply的账户，可惜给我的mail里面没有说明，于是就又去checkout的申述页面，提交了和上次一样的证明信息，并把和这位客服的来回mail放到了其他信息中。结果，第二天早上就收到了账户解封的mail。

我觉得没啥很难得地方，就是要和他们沟通，主要是表明，自己就是信用卡的主人，没有欺诈，祝大家好运

www.mypool.cn ======>>>>  www.hlouis.com

如果有人订阅过我的blog，请将订阅地址更新为：

http://www.hlouis.com/feed/

目前我的cn域名会持续到今年8月份到期，（当然，也可能在中途的任意时刻被停止解析）这段时间内这两个域名会同时指向我现在的网站，所以理论上会有很长的一段过渡时期。。。。。

print("simple test: ")
print((10000 + 123456789) - 123456789)

程序打印出来的值竟然是10003，顿时被雷到了。虽然我知道lua用的是double作为基础的lua_number，但是人家已经很耐心的教育我们double是双精度类型，不会出现什么四舍五入的问题。于是打开linux上的终端运行lua进行同样的计算，这次得到的是正确的结果：10000。

想想也知道lua不会有这种低级的错误的，要不还不立刻被人骂死，于是开始找自己的问题，首先怀疑是我们的lua嵌入包裹代码的问题，仔细review了一遍代码，觉得不会影响到这么底层的问题。接着开始做实验，发现在服务器上的同样lua代码，运行的结果是正确的。经过无尽的折腾，最后发现了这么一个事实：

在directX的sdk文档里面，D3DCREATE这个条目里面有这么一条：

D3DCREATE_FPU_PRESERVE Set the precision for Direct3D floating-point calculations to the precision used by the calling thread. If you do not specify this flag, Direct3D defaults to single-precision round-to-nearest mode for two reasons:
- Double-precision mode will reduce Direct3D performance.
- Portions of Direct3D assume floating-point unit exceptions are masked; unmasking these exceptions may result in undefined behavior

D3D默认在创建设备的时候，会把双精度改成单精度，增加渲染的效率，所以lua也被殃及了，这也算是蝴蝶效应的一个体现吧。。。。。

恶心的问题只要原因找到了解决总是相对容易的，现在有两个方案：

1. 将lua_number定义为int，缺点是lua内就不能使用小数
2. 在D3D初始化的时候添加参数，让他不要改变计算精度，缺点是不知道对性能有多大影响

1. 调用栈全部混乱，一堆问号出现在这里，你明明知道自己编译的时候有放入符号，现在却什么信息都看不到
2. 莫名其妙的调用了一个代码里面没有调用的函数
3. 重复的free或者delete某块内存，然后崩溃
4. 部分静态或者全局的数据混乱了，代码里面除了初始化就没啥地方写过他们了
5. 莫名的某个对象的数据全部混乱了

其实有经验的程序员看到我上面这堆牢骚就知道，归根结底，这些问题都是一个原因：内存混乱。可以直接操作内存是C/C++的效率之源也是一切的罪恶之源。没有个两三年的编程经验，很难深刻的理解内存、指针和引用这些看起来没啥深奥的问题。关于可能出现的内存混乱我大概的归纳一下：

• 使用没有初始化的内存
• 内存越界
• 内存泄漏

为了理解如何处理这些情况，我们先稍微总结一下程序的内存的使用会出现在什么地方：

• 静态，全局内存：静态和全局对象会在main函数之前由libc进行初始化和分配，他们因该会出现在运行的数据段上，一般来说是数据段的开头部分。问题2， 4和5可能由这种内存的混乱引起。
• 栈内存：基本上可以认为是局部变量初始化的内存了，在程序入栈的时候分配，出栈的时候丢弃。这种内存混乱可能会引起问题1, 2, 4, 5
• 堆内存：由malloc、new分配，由free、delete回收的内存。这种内存混乱的话，会引起2、3、4、5

基本上想要彻底在机制上解决内存问题，肯定是没有希望的，因为如果这是可行的，那么早就有nb的人做出来，并放到标准里面了。于是他们做出了java。。。。。所以我们现在追求的就是如何能够快速的追踪到问题的源头。

不像是其他的逻辑bug，内存混乱引起的问题，现象是千奇百怪的，而且发生问题的源头往往和现象不在同一个调用栈里面，或者是整个调用栈全部乱掉，让你无从可查。所以必须要使用一些其他手段来帮助我们。根据不同的内存使用种类，我说一下自己的思路，和目前已经有的做法：

• 堆内存：为什么先从堆开始说起，因为堆上的内存分配和删除是完全控制在我们自己手里面的，说实话，这块东西早就有很多的工具和代码进行跟踪保护和分配了。而且相关的原理基本相通。
  • 最完整的办法解决这个问题是建立自己的内存管理体系，使用内存池，托管系统的malloc、free或者是new、delete。这样不仅仅可以在犯错的时候我们有机会去监测或者记录。还可以通过内存池来增加系统的效率。
  • 如果暂时没有成体系的内存管理系统，也可以使用第三方工具，比如非侵入式的valgrin或者是编译到代码里面的efence。这些工具都可以很好的帮你监控报告这些内存的混乱。
  • 对于内存溢出这个问题，不论是自己的内存管理体系还是第三方的监测工具，基本上都是一个原理。在分配内存的时候多申请一定的字节，比如20个bytes，并将他们初始化为一些特殊的字节。然后去检查这块内存有没有变化。如果有变化就是出现了溢出。最佳的方法是用cpu或者是操作系统提供的内存保护机制，这样一旦有任何的要对这块内存的操作指令，就会立刻break出来，这时再用gdb等的debug工具就可以直接查看调用栈找到元凶。较差的方法是定期或者是析构的时候监测，不过这样效果不好，只能知道到底有没有溢出，或者是哪块内存溢出。到底是谁干的，还是要大海捞针。
• 栈内存：栈内存的混乱基本上会死的很直接，不会让问题慢慢的慢慢的变大。不过栈内存的特殊性，会导致他把案发现场的很多痕迹抹去，因为栈混乱了，所以你看到的调用栈完全是混乱的。你不知道出现的原因是什么。
  • 对于这种情况，我暂时使用了一种看起来有点简陋的方法。就是使用一个buffer来手动的存储目前的调用栈。入栈的时候通过宏把函数名加入buffer，退栈的时候通过宏把函数名移除。坏处是增加了入栈出栈的代价，同时要记录的函数需要在开始和结束的时候添加宏。
• 静态、全局内存混乱：这块是比较复杂的，特别是出现了这种内存的溢出，他会悄无声息的抹去你很多的全局，静态变量，但是系统依然可以运行，不过很多依赖于这些变量的行为都会变的无法预测，天知道这时候会做出什么变态的事情。同时这种内存的分配是在进入main之前发生的，我们完全无能为力。想要对付这种内存我建议。。。。。
  • 在开发小组中规定。。。。不要使用这种内存。

# IBUS was confilict with OOO3 under awesomedon’t know why, but add the blow  
# line, everything OK then~ cheers

OOO_FORCE_DESKTOP=gnome export OOO_FORCE_DESKTOP 

• Use global or static method? 
• Use event class and vritual method call?
• How to handle the memory between caller and callee?
• How to pass context, use pointer? use handle?

这些积累都是SNS和BBS最有价值的部分，新用户往往是为了寻找这样的信息而进行注册和翻阅的。时间越悠久的社区这种有价值的信息就越多。然而我们的BBS和SNS几乎没有提供任何有用的工具帮助用户们来组织，保存分享这样的信息，而是依靠用户自己进行整理和归纳，唯一提供的功能大概就是“置顶”这个功能了。

如果SNS和BBS可以有效的整理归纳和更新这样的信息，肯定可以从中得到好处。让用户更加容易找到信息，可以扩大用户数量。将这些信息中提到的物品进行销售（比如水冷装置，或者某种食谱提及的配料）可以带来一定量的盈利。

程序员是这样 一群家伙，他们可以把1000行代码写成10行，当然也可以把10行代码写成1000行。他们可以让这1000行代码比那10行容易看懂效率更高，也可以 让那10行比这1000行容易看懂效率更高。

我非常同意这样的看法，一个程序员如果在脑袋糊涂，精神萎靡的情况下写出代码 ，往往是逻辑不清楚，只是想把事情糊弄过去，久而久之，众多的小问题就积累起来，让整个项目陷入泥潭，并进入不得不重构的境地。

一个程序员，如果一天可以集中精力，进行5个小时以上的高效工作，并在这段时间内保持思路清楚，编写出高质量的代码，我觉得他肯定已经是顶级的程序员了，精力过人并且技术扎实。对于我们这样的正常人来说，一天可以维持三到四小时这样的高效工作就已经是很了不起的事情了。对于这段高效高质时间，我们应该加以充分的利用。对于效率偏低的时间，我们应该换一个策略来进行工作，这就是我想要说的，对于程序员的工作安排，应该有Hard word和Soft work的区分。

Hard work是指，列在工作项目上的，必须要做完的东西。这些工作项目都是列在整个开发项目的日程表上，不可或缺的环节。
Soft work是指，并没有列在整个项目的开发日程表上，但是对于技术储备，思路拓展都很有帮助的任务。进行Soft work应该可以让程序员enjoy其中，毕竟如果你对学习新技术没有兴趣，估计程序员的职业也就不适合你了。

对于项目的管理人员，挑战的任务就是如何分派两种任务，如何引导程序员进行Soft work，并控制这两种工作所需消耗的时间，如何帮助程序员了解并提高自己的高效工作时间，并可以让他们在早上打开电脑之后就能很明确的知道：今天的工作是什么，哪些最重要，哪些优先级别最高。

近来在互联网上看到，有人在网上做了一个调查，发现有80％的人听到过,每次都是2－3声象弹珠球跌落在地上又弹起的声音…
每次都是2－4声….而且都是在半夜听到，声音好象还挺重的
现在的小朋友还玩弹珠吗？
并且有时还听到麻将骰子掉地的声音！
还有有时也可以听到好象一些家具搬动的声音，仿佛是人在拖一样！

以前还一直疑惑是什么原因，当时也并不怎么在意！没有深究其原因！但是通过互联网以后，发现很多朋友都似乎听到过这种来历不明的声音！！！这就奇怪了，全国各地难道都会出现这样的情形吗？？？这不是特别针对与个人的事情呀？

究竟是什么原因呢？是热膨冷缩吗？

实验一：真的跑去楼上打弹珠，发现声音根本几乎是听不到，其实地板比一般人想象中要厚得很多，顶多像文具、手表之类掉到地上的声音，如果这都听得到~那我看还得了，楼上一举一动你都听得到。

实验证明声音能否传到楼下和那个东西的重量有很大关系，也许这有声学或物理上的原因吧，在此就不探究了，总之就算刻意把弹珠很大力砸在地上~~也要夜深人静又很仔细听才听到一些(而且声音种类也不像)

实验二：一块1*1*0.17公尺的水泥块，内嵌钢筋网和两根水管
在实验室用压克力玻璃罩住里用热空气加热法；加到比室温高50度后持续90分钟，之后罩子打开浇冷水加吹风扇急速冷却，结果……啥事也没发生~什么鬼声也没有.

实验三：同样水泥块同样步骤，这次用半虎钳+铁板把前后左右抵住卡紧；结果……啥事又没发生~边缘有非常非常细的小小裂纹而已~什么鬼声也没有

那么~到底答案是什么??

原来元凶就是霉菌!!

是一种不完全菌纲的霉菌为主会腐蚀工业材料与水泥，好生于多细孔表面，以水泥中矿物质为食。

一般天花板是上下两层的细钢筋作支撑，在灌浆的时候其实钢筋不是笔直的被卡在水泥中，受到水泥浆的流动和重量可能会有向上或向左右的应力累积着，或着房子盖好数年后~受到地震或地基小位移等等因素，细钢筋又会产生新的应力。

在天花板的偏下层有电灯线路的管线出口，有温度与空气等等所以霉菌会沿着该孔开始逐步入侵水泥中缝细，细钢筋与水泥接触面是最理想缝细，霉菌多聚 生于此，菌丝向四周开始侵蚀成一个中空型管道。当某根有应力钢筋的周围水泥被侵蚀到一定程度后便会在中空管道中来回弹动，这就是弹珠声的来源。

所以实验下一步就刻意制作水泥块后；中间夹入比钢筋略粗的塑料棒形成中空道，水泥半干后拿出塑料管插入钢筋，再从另一端灌一些水泥固定。

事实证明，细钢筋在管道中弹动的声音和弹珠声是最像的。

这解释了以下几点

1.声音源不在墙内就在墙外，考虑许多人根本楼上无人住之类种种情形，且都是相似弹珠声；声音源必在墙内，墙内东西就是水泥、水管、钢筋、电线这四种，热帐冷缩已经排除，那这就是逻辑上唯一解释。

2. 既然多发生在下方钢筋网，所以都是听到从天花板传来，楼上要听到由地上传来可能当时要刚好耳贴近地板，这机率就小多了，因为事实证明厚水泥隔音效果比想象 中强，如果上方刚好放有大家具就更难听到了，且很少人天花板会贴东西，地板却常常贴有瓷砖或木头~更阻隔了声音传导。也许有人打地铺睡觉时运气好才会听到 吧。

3.这又解释了为什么几乎没人听过墙壁传出弹珠，因为隔间墙多半是砖墙根本没钢筋，机率就少太多，就算有；听到什么也会以为隔壁在钉东西。

这事情在所谓“管理者”眼里是个笑话，在他们那里几个参数是等同的，加班＝＝工资＝＝产能。事实上每个工作过几年的人都知道这不可能。程序员是这样 一群家伙，他们可以把1000行代码写成10行，当然也可以把10行代码写成1000行。他们可以让这1000行代码比那10行容易看懂效率更高，也可以 让那10行比这1000行容易看懂效率更高。

在这种情况下，我更愿意在质量和工作量中找一个平衡点。即，不让任何一个人累着，不要让他们早晨起来躺在床上懒得上班，不要让他们因为加班被家人抱怨甚至感情危机。人首先是生活的人，如果放弃了生活，工作也没意义。皮之不存，毛将焉附？

最终找到的这种平衡点很有趣。那就是，程序员很难在一天内完成超过4个小时的高效工作。我说的是要求质量，有能动性，要动脑子，有创意的那种工作，拼贴代码那种机械工作咱们就不讨论了。因此我尝试在我和tiny的新公司实行每天6小时，每周30小时工作制。同时我们在力所能及的情况下不主动压低任何人的工资。我们不用期权引诱人，我们首先保证所有人生活正常，无压力，虽然我们认为我们的期权很值钱。但值钱不值钱这件事不是自己吹牛吹出来的，是大家共同努力出来的。

事实证明，每天6个小时工作时间不但没有降低效率，反而比8个小时高很多。想想也不奇怪，早晚放弃了1个小时，所有人都可以躲过早晚交通高峰，路上花费更少的时间，不会被人挤，心情不会太差，到公司可以很快进入工作状态，且心情轻松。

我倾向于相信，如果生活稳定，家庭幸福，收入正常，且在做一份有未来的事业，所有人都愿意尽自己最大努力。反之，其实所有人都有去稳定的大公司的机会。没人愿意来创业。

说到这里，一定会有人反驳：软件工程就是用来降低程序员不稳定性，工作量不够，产品质量不高的问题的。是的，这种说法完全对，不过仅限于外包领域。 外包领域具有明确的需求和验收标准，产品相当稳定。他们追求的是重复性，可复用性。因此他们希望通过一种机制，让程序员变成机器。一个程序员“坏了”（不 开心了，辞职了，老了精力下降了），那就换一个，就好像换掉一个巨大机器上面的齿轮，咔的一声，拧好螺丝，继续运转，一切都跟没发生过一样。刚才那个被拧 下的齿轮呢？老天，谁关心那个。

在互联网，尤其是带有较高技术含量的领域，或是新鲜的领域，我们因为没有标准可循，所以并不需要这种机器。我力图把程序员重新还原成人。所以我更喜 欢创造一个有温情的环境。其实不仅仅我这个小创业者的胡思乱想，google给员工极度的自由，极好的待遇，我觉得也可以看做这种思路。google知道 无法管理技术人员，所以他们干脆选择了彻底的，全面的妥协。一切都交给你们，你们努力去做就好，我们不给你压力。事实上，在选好人的情况下，这种思路产生 的产能是惊人的。当然，在中国似乎没选好人，所以产生的浪费也是惊人的。

几乎所有武术都在讲，出拳的时候手臂要放松，接触目标的瞬间发力，这样才有力量。如果出拳即发力，则会导致肌肉紧张，动作变形，最终你使出了全身的力气，却只打出了软绵绵的一拳。这多么的悲哀。

这篇文章转载自Fox的研究论文的开题报告，写的比较细致，和我目前所做得工作也比较相似。不过行文的水平比我高，把很多我说不明白的事情都表达了出来。很多具体的问题没还有深入，期待后续的文章

Author: Fox(yulefox@126.com)

一个MMORPG（Massively Multiplayer Online Role Playing Game）的架构包含客户端和服务器两部分。客户端主要涉及计算机图形学、物理学、多媒体技术等，服务器主要涉及网络通信技术、数据库技术，而人工智能、操作系统等计算机基础学科知识的应用体现在MMORPG开发过程中的方方面面。

一、游戏世界的划分

理想状态的游戏世界仅由一个完整的场景组成，在《魔兽争霸III》、《CS》这样的单机游戏中，所有玩家位于该场景中，在理论上，位于该场景中的任意玩家都可以看到游戏中所有玩家并与之交互，出于公平性和游戏性（而不是技术上）的考虑，游戏中并不会这样做。

然而，目前的MMORPG中，几乎没有任何一款可以做到整个游戏世界只包含一个场景，因为在一款MMORPG中，同时在线的玩家数量成百上千，甚至是数万人同时在一个游戏世界中交互。以现在的网络技术和计算机系统，还无法为这么多玩家的交互提供即时处理。因此，MMORPG的游戏世界被划分为大小不等、数量众多的场景，游戏服务器对于这些场景的处理分为分区和无缝两种。

在分区式服务器中，一个场景中的玩家无法看到另一个场景中的玩家，当玩家从一个场景到另外一个场景跨越时，都有一个数据转移和加载的过 程（尤其是从一个分区服务器跨越到另外一个服务器时），玩家都有一个等待的时间，在这段时间内，服务器的主要工作是实现跨越玩家数据的转移和加载以及后一 个场景中玩家、NPC等数据的传输，客户端的主要工作是实现新场景资源的加载和服务器通信。主要时 间的长短主要取决于后一个场景中资源数据的大小。分区式服务器的优点主要是各分区服务器保持相对独立，缺点是游戏空间不够大，而且，一旦某个分区服务器中 止服务，位于该服务器上的所有玩家将失去连接。

所谓无缝服务器，玩家几乎察觉不到场景之间的这种切换，在场景间没有物理上的屏障，对于玩家而言，众多场景构成了一个巨大的游戏世界。 场景之间，甚至服务器之间“没有了”明确的界线。因此，无缝服务器为玩家提供了更大的游戏空间和更友好的交互，实现了动态边界的无缝服务器甚至可以在某个 服务器中止服务时，按一定策略将负载动态分散到其他服务器。因此，无缝服务器在技术上要比分区服务器更加复杂。

目前国内上市的MMORPG，大多采用分区式服务器，做到无缝世界的主要有《完美世界》和《天下贰》等，国外的MMORPG中，像《魔兽世界》、《EVE》等，都实现了无缝世界。

无缝服务器与分区式服务器在技术上的主要区别是，当位于场景S1中的玩家P1处于两个（甚至更多）场景S1、S2的边界区域内时，要保证P1能够看到场景S2中建筑、玩家、NPC等可感知对象。而且边界区域的大小要大于等于P1可感知的范围，否则就可能发生S2中的可感知对象突然闪现在P1视野中的异常。

无疑，无缝世界为玩家提供了更人性化和更具魅力的用户体验。

二、无缝世界游戏服务器的整体架构

MMORPG的服务器架构从功能上主要划分为三种：

1、登录服务器（Login Server）

登录服务器用于玩家验证登录，并根据系统记录玩家信息得到其所在节点服务器，并通过世界服务器为登录玩家和对应节点服务器建立连接。

2、世界服务器（World Server）

世界服务器将整个游戏世界划分成不同场景，将所有场景按一定策略分配给节点服务器，并对节点服务器进行管理。世界服务器的另一功能是与 登录服务器交互。因此，世界服务器是登录服务器、节点服务器的沟通桥梁，当然，一旦玩家登录成功，世界服务器将主要处理节点服务器间的通信。因此，世界服 务器对于玩家是透明的。

3、节点服务器（Node Server）

节点服务器负责管理位于该节点的所有玩家、NPC的所有交互，在无缝世界游戏中，由于边界区域的存在，一个节点服务器甚至要处理相邻节点上位于边界区域的玩家和NPC的信息。

在具体实现上，不同的MMORPG为了便于管理，可能还会具有AI服务器、日志服务器、数据库缓存服务器、代理服务器等。

三、无缝世界游戏服务器的主要技术需求

1、编程语言（C/C++、SQL、Lua、Python）

2、图形库（Direct 3D、OpenGL）

3、网络通信（WinSock、BSD Socket，或者ACE）

4、消息、事件、多线程、GUI

5、OS

三、无缝世界游戏服务器需要解决的主要问题

1、资源管理

无论是服务器还是客户端，都涉及到大量资源：玩家数据、NPC数据、战斗公式、模型资源、通信资源等。当这些资源达到一定规模，其管理的难度不可忽视。而且，资源管理的好坏，直接关系到游戏的安全和生命。

2、网络安全

安全永远是第一位的，我们无法指望所有的玩家及其所持的客户端永远是友好的。事实上，威胁到游戏的公平性和安全性的大多数问题，归根结底，都是由于网络通信中存在的欺骗和攻击造成的，这些问题包含但不限于交易欺骗、物品复制。

3、逻辑安全

逻辑安全按理说应该是游戏中最基本的考虑，覆盖的范围也最广最杂。随机数系统是一个非常值得重视的问题，随机数不仅仅用于玩家可见的一 些任务系统、战斗公式、人工智能、物品得失等，还可用于网络报文加密等。因此，随机数系统本身的安全不容忽视。另外一个常见的逻辑安全是玩家的移动，最主 要的就是防止加速齿轮这样的变态操作。

4、负载均衡

MMORPG中的负载均衡包括客户端及服务器资源管理和逻辑处理的负载均衡，其中最难预知的是网络通信的负 载均衡，正常情况下的网络通信数量是可以在游戏设计时做出评估的，但因恶意攻击造成的网络负载是无法预测的。因此，负载均衡所要处理的主要是实时动态负载 均衡和灾难恢复。负载均衡需要解决的问题包括负载监控、负载分析、负载分发和灾难恢复。

5、录像系统

录像系统的构建，主要用于重现关键数据的输入输出，如玩家交易、玩家充值，或者当bug出现后，为逻辑服务器（泛指上文提到的所有类型服务器，主要是节点服务器）相应部分启动录像系统。待收集到足够数据后，通过录像系统重现bug。为了使逻辑服务器不受自身时间（如中断调试等）的影响，还可以专门设计心跳服务器来控制数据传输。

四、总结

在MMORPG中，真正的bug永远存在于将来。从这一点出发，关于MMORPG中游戏世界的构建，怎样苛刻的思考都不为过。

参考资料：

1、 [美] Kim Pallister编, 孟宪武 等译. 游戏编程精粹5, P467-474, P516. 人民邮电出版社, 2007年9月. 北京.
2、 [美] Thor Alexander编, 史晓明 译. 大型多人在线游戏开发, P174-185. 人民邮电出版社, 2006年12月. 北京.
3、 [美] Dante Treglia编, 张磊 译. 游戏编程精粹3, P117-122. 人民邮电出版社, 2003年7月. 北京.
4、 [美] Mark DeLoura编, 王淑礼 等译. 游戏编程精粹1, P90-93. 人民邮电出版社, 2004年10月. 北京.
5、 [美] Douglas 等著, 於春景 译. C++网络编程 卷1. 中国电力出版社, 2004年11月. 北京.
6、 [美] Stephen D. Huston 等著, 马维达 译. ACE程序员指南. 中国电力出版社, 2004年11月. 北京.
7、 [美] Erich Gamma等著, 李英军 等译. 设计模式. 机械工业出版社, 2000年6月. 北京.
8、 游戏引擎全剖析. http://bbs.gameres.com/showthread.asp?threadid=101293.
9、 服务器结构探讨：登录服的负载均衡. http://gamedev.csdn.net/page/351491d0-05ad-48a4-85e1-77870bc1eef3.
10、服务器结构探讨：最终的结构. http://gamedev.csdn.net/page/28695655-974c-4291-8ac4-2589c4e770d3.
11、谈谈网络游戏服务器解决方案. http://www.beareyes.com.cn/2/lib/200411/08/20041108102.htm.
12、负载均衡——大型在线系统实现的关键(下篇)（服务器集群架构的设计与选择）. http://blog.csdn.net/sodme/archive/2005/06/15/394576.aspx.
13、云风的BLOG. http://blog.codingnow.com/

/*****************************************************************************
从0:00到5:00，在写这篇随笔的过程中，我翻找、点击着上面的这些资料，其实还有更
多的资料，没有记在上面，算是为开题做的准备。现在依然是睡意全无。越写越觉得
不够，越想越觉得还有更多东西写不出来……
PS：这些资料大都不是第一次翻，以前看这些资料大多只是单纯的看，现在有目的的
看，才觉得都写得很有味道。不管是不是同意所有观点，都不是本文讨论的重点。
*****************************************************************************/

So you’ve published your Flex application that accesses local XML, but when you try to run it outside of your Flex Builder folder, you might get a Flash Player Debugger error #2148. I ran into this problem while on a tight deadline, and am reposting here to get the word out.

To fix this, you need:

1. to right/control click your Flex Project folder in the Navigator
2. Select properties
3. Choose Flex Compiler in the popup window
4. Add “-use-network=false” under Additional compiler arguments

Hopefully, this’ll save someone some time…

如上所见，左边是Quicksilver根据我让键入的字符在系统中寻找到的对象，右边就是针对这个对象所做的动作，用户可以使用默认动作或者是使用其他的动作。例如针对一个文本文件就有预览，打开等动作。

没有看过Quicksilver的代码，不过相信要我做一个这样的类似程序，我也一定会做这样的内部设计：

对象 — 动作

将对象和动作分别封装成两种最基础的类型，让他们之间有一定的属性可以互相交互从而形成关联。对于程序设计者来说，这个可能是最基础的想法。Quicksilver也忠实的将这个想法反应到UI上。程序设计师对于软件的理解肯定要比一般的使用者深入，如果我们能将一个好的设计暴露到UI上，往往可以给普通用户带来更好的体验。

数据服务器，一下简称DS，用来保存游戏中的数据，他存在与持久层之上，逻辑层之下，是一个针对逻辑层的数据持久层。

为什么需要这层

在我开发游戏服务器以来，发现的一个最严重的问题就是，游戏数据的安全和正确。对于游戏的数据我们大体可以分出一下两类：

• 临时数据：由游戏运行时生成，无需进行保存。在玩家下线或游戏服务器关闭之后就可以抛弃。
• 持久数据：游戏人物的数据、游戏中的物品，人物排名等等由玩家或服务器创造出的并有保存价值的数据

对于一款网络游戏来说，数据基本上是一切。玩家丢了数据等于是被盗号，运营商如果丢了很多玩家的数据基本上就无法正常的运营下去。对于数据可能出现的问题如下：

1. 数据回档：档的原因多种多样， 大体有以下的原因：
   1. 服务器崩溃导致距离上次存档的数据没有保存
   2. 人物数据错乱，导致游戏无法将该玩家的数据保存（和数据库中的某些限制出现冲突）
2. 数据存储效率低下，导致玩家存储数据的时间长于每次存储的间隙
3. 游戏中的物品产生复制，在游戏中的交易的双方交易后出现某一方的回档，物品就会出现复制
4. 数据保存复杂、危险，由于程序员的大量开发工作主要针对于服务器的逻辑，如果需要兼顾撰写保存数据的SQL，很可能出现问题

针对游戏服务器的数据的重要性和易错性，我觉得非常需要添加一层数据层，使游戏数据库对游戏服务器的逻辑透明，同时提供一些简单的方法保证数据的一致性。

具体要求

针对以上的分析，我觉得一个合格的DS需要做到一下的条目：

• 使SQL对使用者透明：
  在这里我们假设，数据库的最终保存持久层依然是某种数据库，那么DS因该可以使用定义的数据类型自动生成保存，更新和读取的SQL语言。撰写逻辑的程序员，只需要定义数据类型和结构，完全不需要考虑和数据库的操作。数据库对于游戏逻辑程序员来说是完全透明的。
• 数据需要有权限概念：
  第一个对某个数据进行访问的用户（其他的游戏逻辑服务器）是该数据的拥有者，拥有者可以限制其他访问者对该数据的权限，是否可读，是否可写等。同时拥有权可以放弃或移交。
• 支持对数据的原子操作：
  对于交易等数据操作，可能需要同时更新两个以上的数据单元，这时候需要提供原子操作的支持，如果某个数据单元的更新不成功，就要让整个操作回滚。
• DS本身的稳定以及自我恢复：
  DS本身的逻辑应该足够简单，并保证服务稳定，内存占用合理并可以在配置文件中调整。DS如果发现持久层出现错误，比如无法连接到数据库，可以通知客户终止操作，并将当前DS内存的数据dump到本地文件，等待问题修正后可以重新Load到内存中。
• 多个DS的分布处理：
  由于DS的内存和效率等的限制，对于一个游戏应用来说，一个DS可能无法承担所有的应用，需要考虑DS的分布处理。分布处理可能会涉及到很多细节，导致复杂度大大增加，希望有时间，我可以继续讨论这个问题。

iptables is a command line tool which allow system administrators to configure Linux packet filtering ruleset.

Using iptables, you are able to tweak packet filtering, Network Address Translation (NAT) and packet mangling which in the end are going to allow you to secure your server, share your Internet connection and log unwanted traffic.

iptables is not really what we could call an easy to get with tool, but once you know the basis, it won’t be that scary .

This tutorial will provide a sample script you can use to share your Internet access and will give an overview on how to use iptables

1. Introduction

Most people will be freaked out when you pronounce the name iptables because it is not much of an easy to understand software, man page is huge as well as iptables capabilities.
To be able to set up a home router, you don’t actually need to spend nights and nights going through iptables man page, a grasp of the basis is enough to get your firewall up and running.

This tutorial provides a sample script you should be able to use out of the box or at most, changing 2 parameters will be able to get you running.

2. Iptables

To be able to understand what the firewall do, there is some basis you need to know. Here I’m going to go over what make iptables handle network packets.

2.1. Chain Rules

Iptables use a set of chain rules to check weather or not a packet should be accepted. By default, there is 3 chains:

• INPUT: packet is destinate to the machine running iptables
• FORWARD: packet needs to be forwarded to another machine
• OUTPUT: packet going out of the machine running iptables

So when a packet reaches the firewall, the first thing the kernel is going to do is to determine where the packet is going. According to the destination, the kernel will check the packet against the rules of the appropriate chain.

2.2. Actions (TARGET)

For each chain we define a list of rules and actions (called targets in iptables’jargon) to take when a packet match a rule. Main actions are:

• ACCEPT: accept the packet
• REJECT: discard the packet and inform the source
• DROP: discard the packet but don’t say anything to the source

As soon as a packet has matched a rule, the kernel will apply the action it is said to do and won’t go further. If the packet did not match any rules, the kernel will use the default policy defined for that chain.

This beeing said, we can now get into the script.

3. Iptables Script

OK, now that we know the really basis, let see what the script is going to look like.

In this example, I assume that eth0 is the interface connected to the Internet, eth1 is the one connected to our local network.

#!/bin/sh
#
# this script requires iptables package to be
# installed on your machine

# Where to find iptables binary
IPT="/sbin/iptables"

# The network interface you will use
# WAN is the one connected to the internet
# LAN the one connected to your local network
WAN="eth0"
LAN="eth1"
# First we need to clear up any existing firewall rules
# and chain which might have been created
$IPT -F
$IPT -F INPUT
$IPT -F OUTPUT
$IPT -F FORWARD
$IPT -F -t mangle
$IPT -F -t nat
$IPT -X

# Default policies: Drop any incoming packets
# accept the rest.
$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT

# To be able to forward traffic from your LAN
# to the Internet, we need to tell the kernel
# to allow ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Masquerading will make machines from the LAN
# look like if they were the router
$IPT -t nat -A POSTROUTING -o $WAN -j MASQUERADE

# If you want to allow traffic to specific port to be
# forwarded to a machine from your LAN
# here we forward traffic to an HTTP server to machine 192.168.0.2
#$IPT -t nat -A PREROUTING -i $WAN -p tcp --dport 80 -j DNAT --to 192.168.0.2:80
#$IPT -A FORWARD -i $WAN -p tcp  --dport 80 -m state --state NEW -j ACCEPT
# For a whole range of port, use:
#$IPT -t nat -A PREROUTING -i $WAN -p tcp --dport 1200:1300 -j DNAT --to 192.168.0.2
#$IPT -A FORWARD -i $WAN -p tcp  --dport 1200:1300 -m state --state NEW -j ACCEPT

# Do not allow new or invalid connections to reach your internal network
$IPT -A FORWARD -i $WAN -m state --state NEW,INVALID -j DROP

# Accept any connections from the local machine
$IPT -A INPUT -i lo -j ACCEPT
# plus from your local network
$IPT -A INPUT -i $LAN -j ACCEPT

# Here we define a new chain which is going to handle
# packets we don't want to respond to
# limit the amount of logs to 10/min
$IPT -N Firewall
$IPT -A Firewall -m limit --limit 10/minute -j LOG --log-prefix "Firewall: "
$IPT -A Firewall -j DROP

# log those packets and inform the sender that the packet was rejected
$IPT -N Rejectwall
$IPT -A Rejectwall -m limit --limit 10/minute -j LOG --log-prefix "Rejectwall: "
$IPT -A Rejectwall -j REJECT
# use the following instead if you want to simulate that the host is not reachable
# for fun though
#$IPT -A Rejectwall -j REJECT  --reject-with icmp-host-unreachable

# here we create a chain to deal with unlegitimate packets
# and limit the number of alerts to 10/min
# packets will be drop without informing the sender
$IPT -N Badflags
$IPT -A Badflags -m limit --limit 10/minute -j LOG --log-prefix "Badflags: "
$IPT -A Badflags -j DROP

# A list of well known combination of Bad TCP flags
# we redirect those to the Badflags chain
# which is going to handle them (log and drop)
$IPT -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ACK,URG URG -j Badflags
$IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j Badflags
$IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j Badflags
$IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ALL ALL -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ALL NONE -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j Badflags
$IPT -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j Badflags

# Accept certain icmp message, drop the others
# and log them through the Firewall chain
# 0 => echo reply
$IPT -A INPUT -p icmp --icmp-type 0 -j ACCEPT
# 3 => Destination Unreachable
$IPT -A INPUT -p icmp --icmp-type 3 -j ACCEPT
# 11 => Time Exceeded
$IPT -A INPUT -p icmp --icmp-type 11 -j ACCEPT
# 8 => Echo
# avoid ping flood
$IPT -A INPUT -p icmp --icmp-type 8 -m limit --limit 1/second -j ACCEPT
$IPT -A INPUT -p icmp -j Firewall

# Accept ssh connections from the Internet
$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT
# or only accept from a certain ip
#$IPT -A INPUT -i $WAN -s 125.124.123.122 -p tcp --dport 22 -j ACCEPT

# Accept related and established connections
$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Drop netbios from the outside, no log, just drop
$IPT -A INPUT -p udp --sport 137 --dport 137 -j DROP

# Finally, anything which was not allowed yet
# is going to go through our Rejectwall rule
$IPT -A INPUT -j Rejectwall

3.1. Iptables default settings

First of all, we define where iptables binary is located and to make the script easier to attapt to other situation, we define the interface as WAN and LAN.
So, if your machine uses eth1 as the interface connected to the Internet and eth0 connected to your local network, simply change:

WAN=”eth0″
LAN=”eth1″

to

WAN=”eth1″
LAN=”eth0″

Then we clean up iptables by flushing all the chain and tables:

$IPT -F xxx

and deleting all the optional user-defined chains:

$IPT -X

Then we define the default policies:

$IPT -P xxx

Which is to DROP any packet which is destinated to the local machine if they were not accepting, ACCEPT any packet which is going out of the local machine or going to/coming from our LAN if they were not discarded yet.

3.2. To and From Local Network

Because we want to be able to forward traffic, we need to say so to the kernel. This is what is done by setting /proc/sys/net/ipv4/ip_forward to 1.

Then, we need to tell the kernel to masquerade all outgoing traffic. This is what is achieved by triggering:

$IPT -t nat -A POSTROUTING -o $WAN -j MASQUERADE

Masquerading has the effect of allowing all computer from your internal network to access the internet. These machines will be seen as if there were the router itself.

Now, suppose you want your apache server on machine 192.168.0.2 to be visible from the outside. You need to tell the firewall to send those packets to machine 192.168.0.2 on port 80, this is what is achieved with:

$IPT -t nat -A PREROUTING -i $WAN -p tcp –dport 80 -j DNAT –to 192.168.0.2:80

But then, you also need to accept new connection on that specific port because, as you will see later on, we by default forbid NEW and INVALID connections coming from the outside to be forwarded.
So, for that specific service, we will allow NEW connections (RELATED and ESTABLISHED being allowed by default) to be forwarded:

$IPT -A FORWARD -i $WAN -p tcp –dport 80 -m state –state NEW -j ACCEPT

And now, let discard any NEW and INVALID connections:

$IPT -A FORWARD -i $WAN -m state –state NEW,INVALID -j DROP

To be able to have your local connection to work properly, you need to accept everything on localhost. This is done with:

# Accept any connections from the local machine
$IPT -A INPUT -i lo -j ACCEPT

We do not need to use the statement $IPT -A OUTPUT -i lo -j ACCEPT because the default OUTPUT policy is set to ACCEPT
If your default policy is different, you might have to add this statement

Then, because in our example we trust our local network (not a wise thing to do though), we need to allow any incoming connections from our LAN:

# plus from your local network
$IPT -A INPUT -i $LAN -j ACCEPT

3.3. Defining custom chains

In order to get a easier to maintain iptables script, it is handy to define some custom chains, also called user-defined chains. This way, you can gather common actions into 1 chain, then, using our target switch (-j) we will be able to send packets that match specific rules to that target.
In order to create a user-defined chain, we need to use:

iptables -N chain_name

and then simply add rules to that chain using the usual:

iptables -A chain_name [rules ...] -j target

Okie, now that this is explained, we are going to create 3 user-defined chains which are going to log packet matching rules to be sent to this specific chain:

• Firewall: is going to log packets by prepending “Firewall: ” and DROP them, as you will see, this will only deal with ICMP
• Rejectwall: is going to log packets (prepending “Rejectwall: “) that were not accepted my any previous rules
• Badflags: is going to log packets which TCP flags are not properly set. Some kind of packets are usually used during attack. (prepending “Badflags: “)

The bit of code that deals with the chain creation and which append rules to it is:

# Here we define a new chain which is going to handle
# packets we don’t want to respond to
# limit the amount of logs to 10/min
$IPT -N Firewall
$IPT -A Firewall -m limit –limit 10/minute -j LOG –log-prefix “Firewall: ”
$IPT -A Firewall -j DROP

# log those packets and inform the sender that the packet was rejected
$IPT -N Rejectwall
$IPT -A Rejectwall -m limit –limit 10/minute -j LOG –log-prefix “Rejectwall: ”
$IPT -A Rejectwall -j REJECT
# use the following instead if you want to simulate that the host is not reachable
# for fun though
#$IPT -A Rejectwall -j REJECT –reject-with icmp-host-unreachable

# here we create a chain to deal with unlegitimate packets
# and limit the number of alerts to 10/min
# packets will be drop without informing the sender
$IPT -N Badflags
$IPT -A Badflags -m limit –limit 10/minute -j LOG –log-prefix “Badflags: ”
$IPT -A Badflags -j DROP

As you can see, there is a new target (action), namely LOG. LOG is a specific target that logs the packet to /var/log/messages usually. LOG is a non-terminating target, this means that the packet is going to continue to the next rule after being logged.
by using the –log-prefix you can specify what is going to be prepended to your log.

So let’s take the example of chain “Firewall”.
First we create the chain: $IPT -N Firewall
Then, we ask the kernel to log the packet and to prepend “Firewall: ” to the log string. But because we don’t want our logs to be flooded by such logs, we cap the number of logs related to the Firewall chain to 10/minute: $IPT -A Firewall -m limit –limit 10/minute -j LOG –log-prefix “Firewall: “
Finally, after we logged the packet, we are simply going to DROP it: $IPT -A Firewall -j DROP

3.4. Using those rules

Creating user-defined chain will now make it easier and faster for us to operate specific actions on packets.
Let’s go through the block of statements related to bad TCP flags:

# A list of well known combination of Bad TCP flags
# we redirect those to the Badflags chain
# which is going to handle them (log and drop)
$IPT -A INPUT -p tcp –tcp-flags ACK,FIN FIN -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ACK,PSH PSH -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ACK,URG URG -j Badflags
$IPT -A INPUT -p tcp –tcp-flags FIN,RST FIN,RST -j Badflags
$IPT -A INPUT -p tcp –tcp-flags SYN,FIN SYN,FIN -j Badflags
$IPT -A INPUT -p tcp –tcp-flags SYN,RST SYN,RST -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ALL ALL -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ALL NONE -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ALL FIN,PSH,URG -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ALL SYN,FIN,PSH,URG -j Badflags
$IPT -A INPUT -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j Badflags

As you can see, for any of the packet matching a rule, we simply have to send the packet to the “Badflags” chain. If we were not using user-defined chains, the first statement would look like:

$IPT -A INPUT -p tcp –tcp-flags ACK,FIN FIN -m limit –limit 10/minute -j LOG –log-prefix “Badflags: ”
$IPT -A INPUT -p tcp –tcp-flags ACK,FIN FIN -j DROP

So this would be twice as much work :s. Now, imagine you want to change the target from DROP to REJECT, you simply have to edit 1 line instead of 11

Those badflags rules are well known combinations of illegitimated TCP flags settings. Normal application should not use those, this is why we can DROP those packets safely.

Now, we are going to allow only a small set of ICMP packets. In our example, we want our firewall to be able to receive information such as Timeout (type 11), Host unreachable (type 3) and we want it to reply to pings (type 8 ) and get replies to ping initiated from our firewall (type 0).
In order to do this, we ACCEPT any ICMP packets which contains one of the following code type and then pass all other ICMP packets code to our Firewall chain.

# Accept certain icmp message, drop the others
# and log them through the Firewall chain
# 0 => echo reply
$IPT -A INPUT -p icmp –icmp-type 0 -j ACCEPT
# 3 => Destination Unreachable
$IPT -A INPUT -p icmp –icmp-type 3 -j ACCEPT
# 11 => Time Exceeded
$IPT -A INPUT -p icmp –icmp-type 11 -j ACCEPT
# 8 => Echo
# avoid ping flood
$IPT -A INPUT -p icmp –icmp-type 8 -m limit –limit 1/second -j ACCEPT
$IPT -A INPUT -p icmp -j Firewall

Note the -m limit –limit 1/second, by doing such, our firewall is going to reply to only 1 ping per second, any other ping will be logged (up to 10/min and then DROPped) through the Firewall chain

3.5. Traffic from the Internet

After we have dealt with not well formed packets and icmp packets, we should apply some global rules to streams coming from the outside (remember that our default policy for OUTPUT packets is ACCEPT, so we don’t have to allow those).

The basic idea here is to only allow streams that are related to a previous connection (useful for FTP for instance) or already established.
But, we are going to make one exception for SSH because we want to be able to connect to our box from the outside.

We achieve this by accepting any ssh packets from the outside and then only connections in state RELATED or ESTABLISHED

# Accept ssh connections from the Internet
$IPT -A INPUT -i $WAN -p tcp –dport 22 -j ACCEPT
# or only accept from a certain ip
#$IPT -A INPUT -i $WAN -s 125.124.123.122 -p tcp –dport 22 -j ACCEPT

# Accept related and established connections
$IPT -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT

Then we are going to DROP silently netbios scan from the outside:

# Drop netbios from the outside, no log, just drop
$IPT -A INPUT -p udp –sport 137 –dport 137 -j DROP

And finally, REJECT any other packet through our user-defined chain Rejectwall:

$IPT -A INPUT -j Rejectwall

4. Using iptables’script

4.1. From the command line

One way to apply the rules we define, is simply to run the script from the command line like:

sudo sh /path/to/firewall-script.sh

but this has the bad effect of not being restore on reboot :s, but still, this will be of great help while tweaking up your firewall.

4.2. Using /etc/rc.local

/etc/rc.local is a custom file where you can add scripts to be executed at the end of each multiuser runlevel.

By default, this file only contain exit 0.
In order to have your iptables firewall script executed on reboot, simply add the path to your firewall script before exit 0.

Copy your firewall script file to /etc/firewall-script.sh for instance. Then make it executable:

sudo chmod 700 /etc/firewall-script.sh

Then edit /etc/rc.local and add /etc/firewall-script.sh before exit 0

Next time you are going to reboot, this script is going to be executed and therefore, your firewall set up restored.

4.3. Using /etc/network/if-up.d/ directory

This one is a bit more tricky.
Once you are done with setting up your firewall script, you will save it to the iptables format by trigerring:

$sudo sh /path/to/firewall/script.sh
$sudo iptables-save > /etc/firewall-iptables.conf

Now, open and edit /etc/network/if-up.d/iptables and make it look like:

#!/bin/sh
iptables-restore < /etc/firewall-iptables.conf

Then make it executable:

sudo chmod +x /etc/network/if-up.d/iptables

Finally, we need a way to set up /proc/sys/net/ipv4/ip_forward to 1. This can be achieved through /etc/sysctl.conf.
Simply add the following entry if not already there:

net.ipv4.ip_forward=1

which will set /proc/sys/net/ipv4/ip_forward to 1 next time you reboot.

We could have also used /etc/firewall-script.sh instead of the iptables-restore trick, but this way, you can see another way to do it

Reboot, your firewall should be up again

4.4. Once upon a time

Debian used to have this great /etc/init.d/iptables init script which allowed you to restore iptables settings on boot up, stop your firewall …
This script is now gone… so we have got to do it by ourself now

4.5. Rescue script

A handy script to have around is a script that can erase all chains and rules in case you are getting lost with your firewall breakages. The following script will clear up all rules and reset all chain so your firewall will be inactive. I suggest you copy it and keep it somewhere close to you in case of emergency.

#!/bin/bash
IPT=’/sbin/iptables’

for a in `cat /proc/net/ip_tables_names`; do
${IPT} -F -t $a
${IPT} -X -t $a

if [ $a = nat ]; then
${IPT} -t nat -P PREROUTING ACCEPT
${IPT} -t nat -P POSTROUTING ACCEPT
${IPT} -t nat -P OUTPUT ACCEPT
elif [ $a = mangle ]; then
${IPT} -t mangle -P PREROUTING ACCEPT
${IPT} -t mangle -P INPUT ACCEPT
${IPT} -t mangle -P FORWARD ACCEPT
${IPT} -t mangle -P OUTPUT ACCEPT
${IPT} -t mangle -P POSTROUTING ACCEPT
elif [ $a = filter ]; then
${IPT} -t filter -P INPUT ACCEPT
${IPT} -t filter -P FORWARD ACCEPT
${IPT} -t filter -P OUTPUT ACCEPT
fi

done

5. Conclusion

This tutorial covered iptables in order to set up a linux firewall which will share your internet connection amongst computer from your local network.
By explaining iptables basis, you should now be able to improve your script so you can allow or disallow specific types of traffic.

This is not the most secure set up though. Best practice would be to set up a policy which disallow all traffic by default and then only allow the traffic you believe that should be permitted.

Finally we went through different ways of recovering iptables setting on reboot.

Hope this helps and will give you enough basis to customize your firewall.

firewall-simple.txt
firewall-stop.txt