我们可以在基本的网络连接之上使用多种不同类型的管道进行客户端与服务器端的通信。基本远程过程调用使用的是标准AMF管道。
另一种通信形式就是消息，这样应用就可以推送来自于服务器端的消息并进行近乎实时的通信。代表性应用就是聊天服务器、拍卖客户端及协作服务。
Data services处理消息的主要方式就是轮询（polling）。由于HTTP上的标准通信并不会一直打开通信管道，这样一个轮询管道就会让客户端请求一 直等待服务器端，直到数据可用为止，其等待时间从几毫秒到几分钟不等。这么做就模拟了从服务器端推送数据的过程。
有两种基本的轮询管道：短轮询与长轮询。其主要区别在于服务器端等到客户端数据变得可用时所需时间的多少。
一种更高级的管道是流式AMF（streaming AMF）。它会打开到服务器端的HTTP连接并让服务器以流的方式在该管道上传输消息（消息的数量没有限制）。这么做就无需客户端轮询了，同时还能使用标 准的网络配置。该方式最接近于实时流。流式AMF的挑战在于它使用了HTTP 1.1的持续连接，而不同的浏览器对其的实现方式却不同。
最后一种管道就是RTMP（实时消息协议）管道了，目前只有LiveCycle DS对其提供了支持。Adobe最近宣布将要发布RTMP规范，由此我猜想它最终将会得到其他产品的支持。
设计RTMP的目的是在双向管道上以流的方式处理大量多媒体和数据。RTMP的一个主要好处是可以一直打开与客户端的连接，这样就可以推送服务器端的数据了。凭借这一点，RTMP可用于Comet风格的通信和实时的数据推送。
RTMP有三种形式。一种是基于TCP并使用1935端口，其底层实现要求在客户端浏览器上初始化连接。由于使用了非标准的端口，这样客户端防火墙经常会阻止其运行。
RTMP的另两种形式在HTTP请求内封装了RTMP消息，这样协议就可以穿越防火墙并使用标准的端口。这两种形式分别是RTMPT（用在标准的HTTP上）及RTMPTS（用在安全的HTTPS上）。
在Flex中，所有对服务器的调用都是异步执行的，因此这些管道都不会对客户端性能造成任何影响。然而他们却对服务器端性能有一定的影响，尤其是在 同时打开多个客户端连接的情况下更是如此。例如，流式AMF会导致服务器端打开大量并发的客户端连接，这也就意味着会产生多个线程。但如前所述，多个线程 的影响微乎其微。
所有的客户端连接都可以配置默认管道和备选管道，如果默认管道失败则可以切换到备选管道上。根据服务器端处理的不同通信类型，我们可以指定不同的管道链。例如，可以指定RTMP管道，但如果该连接失败，就回到长轮询管道。
结论
相对于Blaze DS来说，LiveCycle DS的真正优势在于其支持与数据管理，而额外的端点和管道所带来的优势却是颇具争议的。根据我们在Gorilla Logic所完成的项目来看，根本无需使用NIO端点或是RTMP。但从技术角度来看，没什么是确定的。我倒是想多点项目经历
没有评论:
发表评论