Can sharedObject functionality be mimicked with streaming amf?

Question

Hi
I understand there is no RTMP support in blazeds, and upon some testing done it seems that consumer/producer suffer latency issues (see for example blazeds collaborative dashboard sample application).
i would like to ask what is the way a similar collaborative dashboard application can be develop that will enjoy more "real-time" messaging.
Is SharedObject. RTMP solution the only way?
Thanks
David

Answer 1

Hi David. If you set the log level to Debug in the logging settings in your WEB-INF/flex/services-config.xml file you should be able to see what channel is being used. You should see something like the following printed to the console where the server is running.
[BlazeDS][INFO] Channel endpoint my-streaming-amf received request.
[BlazeDS][DEBUG] Deserializing AMF/HTTP request
Version: 3
(Message #0 targetURI=null, responseURI=/1)
(Array #0)
[0] = (Typed Object #0 'flex.messaging.messages.CommandMessage')
operation = 5
correlationId = ""
timestamp = 0
destination = ""
body = (Object #1)
messageId = "29B90E8D-AED7-0D9B-828F-4C9F2497127D"
clientId = null
headers = (Object #2)
DSMessagingVersion = 1
DSId = "nil"
timeToLive = 0
It's possible you are falling back to a polling channel which would account for the latency/delay you are seeing.
We haven't done any performance comparisons between using remote shared objects in FMS and messaging in BlazeDS/LCDS. We have done comparisons of RTMP and AMF streaming in BlazeDS/LCDS and both have relatively low latency with AMF streaming having slightly less latency than RTMP with the test scenarios we ran.
I'm assuming you can use remote shared objects to do messaging/chat scenarios or you wouldn't be asking the question although I don't know much about how remote shared objects work or how you would use them for messaging scenarios myself. A big difference as I understand it with BlazeDS/LCDS is that messaging is channel/protocol independent. With FMS all communication will be done over RTMP. If your network blocks non http traffic this means that the player will fall back to RTMP polling over HTTP (RTMPT) which is very inefficient. With LCDS you can fall back from RTMP to AMF Polling which will be more efficient than RTMPT. In very high throughput scenarios where lots of messages are getting pushed to clients you will likely get better performance using AMF polling than RTMP because with polling messages get batched up on the server. With BlazeDS/LCDS you can choose which channel to use based on which channel is best suited to the type of application you are building. In general I think BlazeDS/LCDS offers a more robust, scalable messaging solution than FMS at least in my opinion.