Actually, BlazeDS does support push via AMF/HTTP streaming. RTMP supports duplex client-server interactions over a single socket. HTTP is a request/response-based protocol so is not duplex by its nature and in order to simulate a duplex connection the client most open one HTTP connection to the server to receive pushed (or polled) data over, alongside a separate HTTP connection to send data to the server. The client-to-server connection is transient, opened only when the player has something to send to the server.
For streaming AMF/HTTP, the server writes data down to the client directly over the open connection, with no polling involved. Things like Apache connectors or old proxies that buffer HTTP response streams interfere with this, in which case we recommend configuring your ChannelSet to fallback to long polling or simple polling. Long polling provides a better client experience than simple polling on a set interval, because poll requests will be parked on the server to wait for something to return (using a timeout to avoid excessively long waits). For lightly loaded apps, this can significantly reduce the polling load on the server, and it means clients receive 'pushed' messages more immediately then they do with simple polling. Because each poll response is complete (as opposed to streamed/chunked) they are never buffered by connectors/proxies/etc.. BlazeDS doesn't include our NIO-based endpoints (RTMP and NIO-based AMF/HTTP streaming and long polling), so its streaming and long-polling support is implemented on top of the current Servlet API which only supports blocking IO. This means that you must limit the number of streaming or long-polling connections that the server accepts in order to avoid the possibility of putting all the container's request handler threads into a wait state, and we expose config settings for that. The next rev of the Servlet spec is adding limited support for async IO, and at that point BlazeDS will be updated to take advantage of it to scale to higher numbers of streaming and long polling client connections. There's some more info on the channel options/behaviors here: http://www.dcooper.org/Blog/client/index.cfm?mode=entry&entry=8E1439AD-4E22-1671-58710DD528E9C2E7 And the docset for LCDS 2.6 also contains much more information in this area. In answer to the original question, the samples that are included with the BlazeDS turnkey contain some messaging examples. At a high level, you use Producer to send messages to the server and Consumer to subscribe for pushed messages from the server. Take a look at these client-side classes, the server-side Message Service, and the samples that use these. Seth From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Cutter (Flex Related) Sent: Thursday, June 19, 2008 10:24 AM To: [email protected] Subject: Re: [flexcoders] BlazeDS broadcast updates to others? BlazeDS does not have true push (RTMP), it emulates push through polling. Basically your update would push a message to a gateway, that then broadcasts that message to a specific channel for BlazeDS, and the client's polling would pick up that message from BlazeDS in it's next polling cycle (think the default is 8 seconds, but that can be adjusted in the xml config). I don't have a demo, but Andy Matthews is doing a presentation to the Nashville ColdFusion User Group next Thursday night (which will be simulcast over Adobe Connect) that will show an application that does this, and goes into some detail on the hows and whys. (www.ncfug.com should post the Connect URL once it's closer to the preso) Steve "Cutter" Blades Adobe Certified Professional Advanced Macromedia ColdFusion MX 7 Developer _____________________________ http://blog.cutterscrossing.com markflex2007 wrote: > > > Hi, > > I am not sure if BlazeDS have broadcast feature or not that means it > broadcase to other clients when one person update something in the same > Flex application. > > Please give me a demo if you have the url or samples > > Thanks a lot > > Mark
