Many-to-many capability w/interactive server?

Question

Good morning!
I am completely new to Flash server.
We seek to create a remote learning environment (distance learning) with complete interactivity.  In particular, a talk can be delivered simultaneouslty to 20 students.  The students can each see all the other students plus the speaker (as in a boarder of faces around the edge of the screen).  Each is free to converse with the class and teacher (unless capability is turned off by teacher).
Based upon what I have read Flash Interactive server will perform in a one-to-many mode.  Now, how about the many-to-many as described above?  What sort of requirements would be need to be met both at the server and on the individual laptops/desktops/netbooks?
Thanks for your feedback.

Answer 1

What you've described is certainly possible, but may not neccesarily be practical. Having 20 always on video streams will introduce significant bandwidth requirments, and may prove to be a bit more load than the processor in the average netbook is equipped to handle.
Let's consider the 20 participant scenario you described, and let's assume each audio/video stream is published at 100kbps combined. That would mean that each particpant would be consuming about 1.9Mbps of downstream bandwidth, which may not be realistic for all of the participants. On the server side, you'd have 400 streams, and you'd be burning roughly 39Mbps. If you're only running one of these classrooms it may be workable, but if you're talking about multiple concurrent classrooms, the bandwidth requirements will add up fairly quickly, you'd need to expand to multiple servers after you reach the need for more than 3 or 4 of these classrooms, and you'd be burning data transfer at a rate of roughly .28GB per minute per classroom.
There's also the human element to consider. If everyone observes etiquette and people aren't trying to speak over one another, having so many partcipants at once may work. That said, if even a few of the users are talking at once, the experience will degrade pretty quickly.
It may prove more practical to allow the instructor or moderator to allow publishing on an as-needed or as-requested basis, having the concept of "hand raising" via user interface controls and only having a few participants actively broadcasting at any given time (let the moderator select the users who are being broadcast to the group). That way, you can more readily control bandwidth requirements, and the instructor/moderator has an easy means of keeping the experience good for all of the participants