Hi Shailesh, 1. Channel fallback through the channels in your client-side ChannelSet wraps (meaning if RTMP fails you'll fall back to HTTP, and if that fails you'll wrap back around to RTMP). Once your ChannelSet falls back to a different channel, it doesn't attempt to automatically detect that the previous channel/endpoint that failed has become available and revert to it.
2. RTMP fallback to RTMPT is internal and there's no configuration involved on your end. The scenario where you'll observe this fallback is when your client can't establish a direct RTMP connection due to a blocked port or packet-inspecting proxy dropping packets; the player will check the browser's HTTP proxy settings and if an HTTP proxy is configured, it will attempt to tunnel a direct connection through the HTTP proxy. If the browser doesn't have an HTTP proxy configured, the player will fall back to a POST-based polling tunnel but in LCDS 2.5.1 this happens on the same port as direct RTMP connections so if the direct connection was blocked by a firewall due to the non-standard port number these requests will be blocked as well. At that point, the channel will report that it can't connect and the ChannelSet will advance to your next channel and try to connect using that. 3. Pushed data (autoSyncEnabled=true) should work fine over the AMF or HTTP channel/endpoint when you have polling enabled. If you don't have polling enabled, there's no way to move queued updates from the server to the client. If you do have polling enabled, the problem is likely due to a bug in 2.5.1 that is described, along with a work-around, here: http://www.mail-archive.com/flexcoders@yahoogroups.com/msg81602.html 4. When a channel is disconnected or fails due to a server crash or a network issue, Consumers (subscribers) and DataService instances should automatically connect and re-establish their subscription state and data management state. The bug mentioned in #3 may be interfering with this happening in your app. Consumer resubscribes work fine in 2.5.1, and you can control that behavior using the resubscribeAttempts and resubscribeInterval properties on Consumer. Message Producers (publishers) will trigger a reconnect attempt following a disconnect implicitly on their next send(), or you can configure them to proactively trigger a reconnect following a disconnect using their reconnectAttempts and reconnectInterval properties. HTH, Seth From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Shailesh Mangal Sent: Thursday, May 01, 2008 8:17 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Switching between RTMP and HTTP We are using RTMP as our main protocol and HTTP as a fall back. I have bunch of questions. 1. We observed that when RTMP fails, DataService in client automatically falls back to HTTP. But when RTMP comes back, it doesn't reconnects and continues with HTTP. Is there an API to do this (other then client attempting to connect periodically) 2. How does RTMP fall back on to RTMPT (Tunnel). Is there any configuration for this? 3. DataServiceTransaction doesn't seem to work in case of HTTP mode. Is there any work around to push data from server to client in case RTMP is not available. 4. When RTMP becomes unavailable, does message subscriber and publisher have to re- connect to server? Has anybody experienced these issues? WIll appreciate any quick help. -Shailesh
