This content has been marked as final. Show 9 replies
The communication between the Flex client and DS is still a black box for me (and still does not work). I've down some network traces on the client machine. But I see only the attemps from the client to connect on port 2038 (RTMP). Of course this will not work.
As I understand, if the direct connection does not work, the client should start a polling mechanism to implement bidirectional communication between the browser and the server over http.
1. When starts the client the polling mechanism? Is there a RTMP time out?
2. Does the polling really start automatically or is there a configuration file?
3. Is there a debugging mode for the connection?
PS: Here you can find an overview of the connections possibilities: http://blogs.adobe.com/flexdoc/2007/07/realtime_messaging_with_livecy_1.html
With network topologies like yours that are a complex and HTTP-specific, the RTMP/T protocol is difficult to deploy successfully. The client-side RTMPChannel first attempts to make a direct connection (a TCP socket connection) to the RTMP endpoint. If this fails (and it probably will considering all your firewalls and reverse proxy) it's usually because something in the network path is doing stateful packet inspection and is only allowing HTTP traffic. Some components will reset/close the TCP connection but many will just silently drop packets and the player is not notified. You can configure the connect-timeout-seconds property for this channel/endpoint to make it give up after waiting a few seconds and not hearing anything back. So that's the answer to the RTMP time out question.
Two seconds after the client RTMPChannel makes its direct attempt, if it hasn't successfully connected or received a network fault the channel will start up a second, concurrent tunneled connect attempt (RTMPT). Whichever of these two connection attempts is successful wins and aborts the other; at which point the channel is connected to the server over a direct connection or a tunneled connection (whichever was able to successfully connect). Note that the connection-timeout-seconds applies to the total time for both of these attempts, so you'd want to set it to something like 4 or 5 seconds. Using a network sniffer such as Ethereal and filtering for traffic on over the port you're using for RTMP you'll be able to watch these attempts go out. Given the complexity of your network you may need to packet sniff at a few points to sort out where packets are being lost.
If you add a
to a simple test Flex app, the debug output will contain some info on what the channel is doing.
Things to watch for: RTMP is often blocked by closed ports or by network components that are operating in an HTTP-mode or only allow HTTP packets. RTMPT depends on a cookie, so if the channel falls back to tunneling you need to be sure that your network components are configured to support sticky HTTP connections for your clients (otherwise the HTTP requests that RTMPT is tunneled over end up going to different LCDS servers, causing problems with the connection).
The reason we added the long-polling support to the AMF and HTTP channels in the 2.5.1 release is because RTMP/T can be such a deployment challenge. I'd really suggest that you investigate that option further before commiting to RTMP/T.
Also, one additional point to reiterate. RTMP and RTMPT target the same server port that you defined in your channel endpoint URI. The fallback tunneled attempt does not switch to a different port. So if your RTMP endpoint binds port 2035 on the LCDS server, that's the port that direct RTMP and tunneled RTMPT connections from clients will need to connect to through your network.
LCDS deploys into a Java web or JEE container, and the container has already generally bound the standard HTTP ports so those often won't be available for the RTMP endpoint to use. RTMP and RTMPT is not, and can not, be serviced by the Java web container and the servlet pipeline.
You can expose an RTMP endpoint on a standard HTTP port by setting up a virtual IP and routing traffic back to the bound port on the LCDS servers. This would allow tunneled RTMPT traffic to occur over a standard HTTP port (80 or 443) without interfering with regular HTTP traffic to the Java web container.
But again, I'd recommend investigating the long-polling support for AMF and HTTP channels added in 2.5.1.
Thanks for your explanations. This raises some new questions:
1. Where we can specify the time out for the RTMP/RTMPT requests?
2. Is there any configuration needed for the polling requests except the endpoint definition (We see no http requests in the network sniffer)?
3. How decides the client to use either "my-http" or "my-secure-http" and "my-amf" or "my-secure-amf" respectively?
4. I understand the RTMP and HTTP endpoints. But for what purpose are the three amf endpoints?
Thanks in advance,
Hi Michael,<br /><br />1. There's no timeout for requests. The RTMPChannel (along with any other channel) supports a connectTimeout property, that will fault the current connect attempt if it hasn't succeeded or failed within the defined timespan. This can be assigned directly in client code or configured in your <channel-definition> in services-config.xml using the <connect-timeout-seconds/> property.<br /><br />2. Tunneled RTMPT does not have a configurable polling interval. It's adaptive and is based on data being sent over the connection in either direction.<br /><br />3. Take a look at ChannelSet and in the doc set to read about how hunting through channels in the set work on the client. ChannelSets may be constructed manually in code, or will be created automatically based on the destination your client component (Consumer, RemoteObject, DataService, whatever) is communicating with. In your server config file that defines the destination, it either has an explicit set of channels defined to access it or it will use the default channels for the service type. These configured channels are what end up in automatically constructed ChannelSets on the client.<br /><br />4. The AMF channels/endpoints send data over HTTP in the binary AMF format, which is more effecient than a text-based encoding. The HTTP channels/endpoints send data in an XML format, called AMFX, that uses the same encoding/decoding rules as binary AMF. The HTTP channels/endpoints are for customers who must only send ASCII data over the network (i.e. no binary data allowed for auditing reason). In general you'll want to use AMF over HTTP because of the effiency gains. RTMP channels/endpoints use the RTMP protocol, and data sent over these connections is also encoded as binary AMF.<br /><br />Seth
1. The question wasn't carefully worded, but the answer is
2. The question isn't related to RTMP it relates to the http channel
I think I have to talk with the developers again. I found in the network sniffer that the browser communicates with the server over https. Perhaps they have some hardcoded stuff in the application. I post the outcome of further analyses.
Thanks and greetings from Munich,
hi i m trying to use live cycle data services and java as back end but i get these errors when i try to get the data using fill method any idea where i m going wrong actually i m using data service and declare the service in service_config.xml and have the assembler class a service class and a java class to define the object and i get the following error
[RPC Fault faultString="Send failed" faultCode="Client.Error.MessageSend" faultDetail="Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Status 404: url: 'http://localhost:8088/rajcon/messagebroker/amf'"]
at mx.data::ConcreteDataService/http://www.adobe.com/2006/flex/mx/internal::dispatchFaultEve nt()
at mx.messaging.channels::PollingChannel/mx.messaging.channels:PollingChannel::connectFailed ()
The error sounds like your endpoint 'http://localhost:8088/rajcon/messagebroker/amf' is not available. If you enter the URL in a browser you should become also a 404 error.
Check the URL Default port is not 8088, but 8080. If this doesn't work check your server configuration.
Hello, I also have a more complex load balancing problem. I'm using HAProxy to load balance RTMPT connections to multiple backend servers. It does the load balancing by inserting a cookie called SERVERID into the HTTP traffic.
I have successfully gotten flash clients to load balance properly but only on windows based machines.
The reason for this is that (at least on Mac OSX based machines), every RTMPT request put out by a client on a Mac (any browser) adds a cookie called "Connection: Close", which causes HAProxy to close the HTTP 1.1 connection, and RTMPT doesn't remember the SERVERID cookie for the next HTTP request.
Is there a way to call netConnection.addHeader(), to properly set a cookie ID? Alternatively, is there a way to stop a flash client in a mac browser from putting in the "Connection: Close" cookie?
Any help would be appreciated.