What are the most network intensive AFCS interactions?

[__Andy]

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?

[Raff_ · Accepted solution]

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.

[__Andy]

Thankyou Raff.

I should really accept the idea that Adobe is offering a super collaboration server that can handle all this data transfer and I don't really need to think about. I need to forget about the restrictions on my own little server....... and think BIG!

BTW: I am not planning the next killer social application.

Thanks again.

[Former Community Member]

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

[__Andy]

Stefan,

The youtube demo works now – thanks.

I appreciate what you and Raff are saying. The considerations regarding real-time data transfer is a new area for me. I am quite a cautious and conservative developer who never really goes for ‘effect’ – I will carefully assess the communicative value of an interaction before sticking it in an application.

I am beginning to build a picture of what is involved (I know this is obvious):

1. Collaborative interactions send messages which get multiplied from the server for each connected user.
2. Flex has to re-render the screen if it receives a message suggesting something visual has changed.

So based on this, like you suggest, I need to manage these depending on the user profile/ or give them the option to manage it themselves, some ways to do this might include (I am just brain storming this):

1. Modular interactions that can be loaded or not
2. Temporarily disabling the messaging activity of a particular interaction
3. Controlling the interaction re-redraw rate
4. Prioritising/filtering messages
5. Prioritising users… sounds odd but you might have a collaboration leader – like a teacher.

Such management issues like these would lead to pods/components that let the user control these aspects - for example they may use a drop down list to switch off/ block the chat messaging, or a graphics screen. I know that sounds like it’s defeating the object of ‘collaboration’ – but I am thinking ‘collaboration’ could be optional in some applications. Plus like you say, I need to consider users have preferences or limitations.

In a nutshell I guess I am saying not everybody in the same ‘room’ is necessarily doing the same thing, but at some point there efforts may come together. A hypothetical example being that I may split a group of students into small groups to work on particular aspects of a project and then bring the efforts together for the big picture. (I am presuming you cannot merge the activities in individual rooms)

So, some kind of ready made (by adobe of course – too complicated for me) flexible, message filtering pod could be useful…. That allows the user to granulise whats happening in a particular room.

Sorry for the long post, you can probably tell I’m only ‘scoping’ out the AFCS at the moment.

Thanks again for your insight.