Posts tagged "channels"

Specifying channel fallback for Flex applications using Data Services

Note: Edited 22 November 2001 to add symptoms that fallback to RTMPT can cause and how to disable RTMPT.

Data Services servers that have a high volume of messaging connections can have a problem in which all available sockets or threads are used. Another point of issue they can have, too, are large worker threads that seem to linger long after they are no longer being used. Sometimes the amount of memory consumed by these threads is great enough that the developer begins to suspect there is a memory leak. It is a particular problem if the number of client application that cannot connect to the server via the conventional RTMP port is large.

The most effective protocol to use for messaging within Data Services is RTMPS. Not all firewalls allow the passing of RTMPS traffic. Messaging between Data Services and Flex can use several protocols, including HTTP streaming. The process of the Flex client using alternative protocols when the preferred do not work is called fallback. Which protocols are preferred and in what order they are attempted during fallback can be configured.

Fallback between Data Services and Flash is mostly programmed within Flash. The server.xml and messaging.xml configuration files define a contract between Flex and the server. Flex reads the configuration files at runtime and follows those specification when connecting to the Data Services server. The Data Services server uses the configuration file to know which endpoints it needs to make available for Flex to use.

Say a developer wants a fallback from RTMPS to the HTTP Streaming. And they need the fallback to be secure. Within the services-config.xml file the configuration for the secure HTTP streaming needs to be added. If the developer is sending XML back and forth they can use HTTP secure streaming. For passing AMF data the developer can use the AMF version of the HTTP secure streaming.

<channel-definition id="my-streaming-amf">
     <server ref="secure-nio-streaming-amf-service"/>


The endpoint, secure-nio-streaming-amf-service, needs to be defined within the configuration like in the same way are for RTMPS.

The fallback order is specified in the messaging-config.xml. So the secure HTTP streaming endpoint needs to be added:

     <channel ref="my-rtmps" />
     <channel ref="my-rtmp" />
     <channel ref="my-streaming-amf" />


The configurations on the server make the fallback endpoints available and gives the Flex compiler a way of knowing the endpoints to use for fallback. Flex does not make a query to the server at run time for the preference order of endpoints. This information needs to be compiled into the client or handled within the ActionScript on the client layer. I am guessing this is done for security reasons. If a client obtained endpoint information at runtime it is possible for someone to point the client to their own servers and hijack your traffic.

One last step must be completed to keep RTMPT from being used. There is a setting to disable it: block-rtmpt-polling-clients. Adding this property to the RTMP channel will disable it.

<channel-definition id="serverRtmp" class="mx.messaging.channels.RTMPChannel">
    <endpoint uri="rtmp://localhost:2037/rtmp" class="flex.messaging.endpoints.RTMPEndpoint"/>
    <server ref="nioserver"/>


How to Set Fallback on the Client

There’s more than one way to set up fallback within your client. Your Consumer class instances have a channelSet property that contains the list of channels to use in order of preference. This information needs to populated within your client. This can be done with just configuration. You can also use MXML and ActionScript to set the fallback.

Specifying Fallback Through Configuration Only

There is a compiler tag, -services, that can be used with the MXML compiler of the Flex SDK. The tag -services should be set to the path of your services-config.xml. When you do this, your MXML will be compiled with the server-specific information. When a new instance of Consumer is created it will have its values already populated with the values you specified in your configuration. If you are compiling an ActionScript-only application or component this value will not be pre-set. I am supposing you at least have a top-level MXML application file.

Specifying Fallback Through MXML

A Consumer instance can be created using MXML.

<Consumer id="msging" destination="messagingDestination">


Specifying Fallback Within ActionScript

The following example shows ActionScript code that is equivalent to the MXML code in the previous example:

private function run():void
    consumer = new Consumer();
    var cs:ChannelSet = new ChannelSet();
            new SecureStreamingAMFChannel (
    consumer.destination = "secureStreamingAMF";
    consumer.channelSet = cs;


Detecting the Type of Channel Being Used By a Consumer

The same channelSet property of a Consumer instance that can be used to set the fallback channels can be used to detect the current channel type. ChannelSet has a the property, currentChannel. Each type of channel has its own class. Those classes can be found in the documentation for the … package. Each channel also has a protocol property. If the channel is RTMP or RTMPS, the value of protocol will be the string, “rtmp.” If the channel is RTMPT, the protocol will be “rtmpt.” For all non-secure HTTP channels the protocol is “http.” For all secure HTTP channels the protocol is “https.”


Real-Time Messaging with LiveCycle Data Services ES

This is very good documentation about messaging and includes information about fallback. A lot of this may be too basic for you, but there is enough here that there may be some details that will help you out.

About channels and endpoints