Skip navigation
::Andy
Currently Being Moderated

What are the most network intensive AFCS interactions?

May 13, 2009 7:18 AM

During the intial design stages of a project it would be useful to know what aspects of the AFCS are the most network intensive, and perhaps the most likely areas to cause delayed collaboration responses. I am asking this because there seems so many tempting 'rich' interactions made readily available through AFCS.

 

For example does video streaming take a lot of resource or is it tracking all the interactions on a whiteboard? Or is it the voice transmission?

I realise it depends on how many users are interacting, for example 100 people chatting might take more resource than streaming one videocam. A rough idea would be useful for somebody like me who has not got any idea what data is being transferred in the background. Otherwise I could assume that I can chuck every pod going into an app and expect it to run smoothly - maybe it would? I have already mentioned on the forum that I personally cannot get the 'You tube Living Room' example to fully initialise without crashing my browser.

 

Is such a list possible to determine? Is it a stupid consideration?

 
Replies
  • Currently Being Moderated
    May 13, 2009 9:00 AM   in reply to ::Andy

    Well, audio/video streaming is for sure heavier than data messaging, how much depends on the compression level (and the compression/decompression method determines how cpu intensive those operations are).

     

    The "load" of data messaging depends on the message payload (a chat is pretty much the chat message + timestamp + maybe some formatting info + the user id, whiteboard messages contain cursor or object position, shape type, some extra info depending on the shape, etc.)

     

    In general, indenpendently of the message type your load is multiplied by the number of users receiving the message (so one video frame sent to 100 people it's 100 times the load of the single message, same for data messages)

     

    You should be able to run the dev console application and "look" at the messages going through. You can see how many properties different items have (chat item vs. whiteboard items, etc.) and that should give you a good idea of how "heavy" each message is relative to another.

     

    One thing to say is that unless you create your own items and, for example, store bitmaps in it, the payload of each standard data message is small enough to fit in a single TCP/IP packet, so while they may use more or less bandwidth, they all "cost" one network packet.

     
    |
    Mark as:
  • Currently Being Moderated
    May 13, 2009 10:20 AM   in reply to ::Andy

    Agree with Raff here - our pipes at the service can handle a lot, so that shouldn't be too much of a problem. It's your clients' connections you need to worry about. If you run the dev console (the AIR app in /extras) on your room while it's doing something, and go to the "Log" tab, you'll get a real-time view of how much bandwidth you're pumping through each client. Basically, know your audience - if you expect DSL customers, try to limit usage to fit that profile.

     

    As to the WeTube app, thanks for pointing out what was happening - I just fixed it now. I'd basically let chat persist forever, so there were 1000s upon 1000s of chat messages in there, which were very slow to render in a Flex TextArea. So I cleared the messages, and all is well. As well, I changed the persistence setting so that it cleans itself up after every session closes down (sessionDependentItems). As well, I noticed that the SimpleChatModel doesn't handle this sort of situation very well at all - it attempts to redraw the UI with every message receipt, instead of once after all the old ones have been received. We'll fix this up for the next SDK drop.

     

      nigel

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points