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=entryentry=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: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Cutter
(Flex Related)
Sent: Thursday, June 19, 2008 10:24 AM
To: flexcoders@yahoogroups.com
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
