1.as的socket---》服务器的socket（比如java）
优势：方便，统一，可能好多服务器端游戏框架都是用这个做借口
缺点：属于tcp编程，需要和服务器端建立一个连接，服务器资源利用会有点紧张
2.as的http组件，类似ajax的访问
优势：用http的方式，和服务器不建立长连接，只是瞬间链接后就释放，不会有长连接资源消耗，80端口规范，可扩展性强
缺点：需要持续的发生请求获得最新的信息，发送请求过于频繁，在人数多的情况下，无论是服务器cpu还是带宽都是消耗很大
3.as->js-->服务器
优势：也是用http，可以用ajax做跳板，可以运用成熟的ajax框架
缺点：好像是多次一举。。。。
4.as->js->activeX（或者applet）-->服务器
优势：可以用udp实现。不用tcp，这样可以有效的降低服务器开销，是上面那么多方法中可以保证最多在线人数的方法
缺点：activeX或者applet对客户端浏览器普遍性不够，可能需要安装什么的。
大家都用哪种？ |
|
********************************************
| socket并不会占用过多的服务器资源吧.网络上所有方式的通信.底层协议基本都是socket.包括http协议等等.socket如果站用过多的资源,原因大部分是由服务器端代码写的不好造成的.比如写了N个傻等待的线程 |
|
********************************************
楼上的兄弟说错了。。。
其实如果广义上来说，socket分为tcpSocket和udpScoket，但是flash中说提到的socket是指TcpSocket。
所谓的tcpSocket，就是需要经过三次握手，然后建立一个链接，在服务器端始终持有这个链接，也就是有多少用户，服务器端始终持有这个用户，这是socket（这里指的是TcpSocket），而我們平時說的http協議，也是基于TcpSocket，之所以他不會占用服務器很多資源，是因为http协议进行，也可以说是web协议的进行，是通过短连接，然后释放，也就是打开一个网页后，socket的建立和断开都已经完成，服务器完全释放了这个socket引用，这种方式其实就是我上面说的http组件或者ajax的方式，这种方式不会占用服务器很多资源，但是由于其天 生的通讯不及时性（我要获得服务器信息，必须发送一个请求，而不能是服务器有信息的时候直接推给你），这也就是说你需要不断的每隔一段时间发送请求检测服务器数据的更新，这样从另一个侧面也增大了服务器负担。
而as3中的socket编程，如果用于网络游戏，一般是一个长TcpScoekt，也就是等三次握手结束后，这个socket连接没有断开，服务器一直持有这个socket，当服务器有新信息的时候直接推送给客户端，这样保证了信息的及时性，但是服务器要为每隔客户端只有一个socket连接，这再一定程度上是费资源的。
反过来说udpSocket，在flash中没有内置udp通讯，udp通讯是一种面向非连接的，也就是不需要建立一个持久的连接，这样服务器资源就可以节省，同样，他也不用向ajax那样频繁请求，因为他可以实现服务器对客户端的推送信息，可以说，udp集合了上面两种方式的优点，当然，他也有缺点，就是数据不检测完整性，我发送给你的信息我不保证完整性，但是在于一般的游戏，聊天来说，这个妨碍不大，如果你要说 “网络上所有方式的通信.底层协议基本都是socket.包括http协议等等”，那么我给你举个例子：QQ就是用的udp，因为如果是用tcp，那么多qq用户，腾讯的服务器要增加至少几倍。
唯一遗憾的是，as3没有内置udp，所以我上面才说考虑用actionX或者applet做跳板，事实上，我有项目是用applet做跳板的，但是由于普及性方面问题，最近的一个项目需要慎重考虑。 |
|
********************************************
flash确实不支持udp，在AS3语言参考里有说明
我觉得楼主的问题很好解决，选1
http协议是tcp协议上的一个应用协议，不断发起http请求等于不断的建立tcp连接，代价很大，并且不实时。
3比2多了一层，更没意义
4里普及率就是一个致命的问题，冲着这个理由就可以否决它。
另外，在网络游戏中，udp和tcp各有优势。在需要传递长消息的情况下，解析多个udp包的开销比解析一个tcp包要大。
在客户端的游戏里，fps用udp较多，mmorpg用tcp较多。楼主既然考虑用flash，多半是虚拟社区和mmorpg吧，应该选tcp的。 |
|
********************************************
| 说的很有道理，你说的 “在需要传递长消息的情况下，解析多个udp包的开销比解析一个tcp包要大”，我确实没有考虑过，不过游戏很少有长消息的，其实我内心也是觉得1方案比较好，但是我一直在想有没有可以把4方案通过一定的方式弥补而使其更完善，比如用flash引导自动安装java的浏览器环境，比如在客户端实在不支持java的时候，启用actionX方案，如果还是不行，就启用socket方案，最终的通道只有一个，但是接受发送引擎可以多个选择，一直在考虑这种方案的可行性，当然如果没有找到一个普及的方法，我还是会选择socket方案的。 |
|
********************************************
| 为何都完全不考虑RTMP的方式？RTMP也是基于TCP Socket实现的吧，效率据测试也是很高的 |
|
FMS就是依靠RTMP大行其道.FMS同时也能轻松胜任游戏的开发,只是FMS服务器开销大,机器要好才行. |
|
********************************************
多一层，对开发人员来说就多一层工作量，多一层不可靠，多一层危险系数
对于用户来说，也是增加了障碍，得到的好处也不见得好到哪里，由于udp连接不可靠，你怎么知道那个消息报属于哪个授权用户的？势必需要每个消息包都增加额外的认证信息，而TCP一但连接被认证可靠，就不需要再考虑虚假用户的问题了 |
|
********************************************
网络通讯用tcp是肯定的，一个有状态协议对游戏来说太重要了。
upd。无状态协议，只适合某些im通讯的状态。。。 |
|
********************************************
如果不是做web game，直接排除http协议的任何方式
active插件依赖于客户安装，不到万不得已，商业性质应用都会排除它，还有安全性问题嘛，有active插件其实可做的事情就多了，想想active可以用c语言写，哎，这个这个……
如果要求数据解析方便，可以采用FMS，但服务器得专门为其写一套解析机制
所以，我个人倾向于使用tcp socket
有空考虑研究下FMS是否有利于提高客户端解析效率以及服务器本身解析FMS有多大损失…… |
|
********************************************
LS，没看出来，你的是用swf做的啊
而且我认为后台的sockets并没有那么恐怖吧，固定的代码就那么几十行，负责广播数据。
剩下的动作基本都是交由flash去完成。
我的webgame也由我一人开发，当然美工除外，我用的就是php的socket和Ajax，多人在线实现的还是比较完美的。
我想知道flash的xmlsocket和socket之间的传输效率差距多少，因为我用的是flash的xmlsocket，很想换成直接的socket，但不知道有没有必要，哪位高人指点一下。 |
|
*******************************************
| 一般webgame都是用tcp socket来做的。这样自主性更大，fms很好，可以数据视频同时交换，唯一的缺点是太贵 |
|