一直都有先烈往这块领域投奔，为flash
产业做出辉煌的贡献，为此今天特撰此文以告后
人避免重蹈覆辙.
MMO APRG游戏
的最关键问题是网络延时，一旦网络延时过大，就会给
玩家造成很差的游戏体验，这点是很致命的，那么flash能不能胜任呢？
除去Adobe
的RTMFP(UDP协议)之外，目前我们在
flash上能用的通讯协议只有TCP，那么它能胜任么？
先讲下TCP数据
的传播方式
假如你想把数据从客户端A发往客户端B，那么数据的发送形式如下：
客户端A -> 服务器 -> 客户端B
有人会想，假如我的客户端A到服务器的Ping值(网络延时)为30ms，客户端B到服务器的Ping值也为30ms，那么A机发数据到B机上也就
60ms，60毫秒的时差对APRG游戏还是可以接受的呀。
很好这样讲是没错的，但是就是因为这样想很多先烈倒下来了。
表面上看60ms是能把数据从A机发往B机，但实际上并不是这么简单。
TCP协议本身默认开启了一个算法
叫做：Nagle。
它是干什么的呢？
简单来讲：它是一个延后发送数据的算法。
当你往socket发送数据的时候，如果发送的数据小于MSS(最大分段长度)，那么你所发送的数据将会延后200ms才发送，这意味着什么呢?
意味着A机发往B机的时间为30+200+200+30=460ms，我想你知道这个结果之后肯定会抓狂。
不过如果幸运的话，编写服务器的人知道把服务器的TCP
Nagle算法关闭了的话，那A机发往B机的时间为30+200+30=260ms，这个结果看起来稍微安慰一点。
刚才上文讲的MSS这里再具体讲一下，它的意思就是每次发送的数据包的最大长度，这个值通常由MTU(最大传输单元)来决定，基本上现在我们的网络设备
(路由器)MTU为1500左右，即每次发送最多1500个字节左右，MSS值等于或稍低于此值。
那么如果你往发送的数据里加一些冗余数据超过MSS值会怎么样，那这200ms延时会减少一半以上，当然不是说你加越多越好，你加多了一会又变成服务器接
收数据时间长了。另外这种方法的副作用是你将会付出几倍的宽带资源及处理资源。
本文到处就结束了，上面说的问题，给的答案，能不能做，就看你怎么想了。
稍带说下，Flash没有提供任何函数来关闭Nagle算法(包括Alchemy)，这点很杯具。
效果出来了,可就是太依赖uCenter了,不知道怎么独立出来
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,0,0" width="447" height="477" id="mycamera" align="middle">
<param n ......
