While it may be impractical to cluster the actual AV data in the stream, perhaps the current state (metadata) of the stream could be clustered so that, as long as the AV data was available on disk at each server, any server could pick up the stream and start serving it based on the metadata about the stream (e.g., offset into the data file, current position of buffers, stuff like that).
Of course, I share Steve Harris's lack of knowledge of the internals of Red5, so my observation might be dumb, nonsensical, or both for which I apologize in advance. Steve, On 6/16/07, sharrissf <[EMAIL PROTECTED]> wrote: > > > Assuming the stream fits in memory and just has multiple people accessing > it > I suspect it could be clustered with Terracotta. Though I would need to > know > more details to know for sure as I'm not that familiar with how they work > and are implemented. My thinking is that everyone in this case is > essentially sharing the same stream so really only one instance ends up in > each jvm and all the meta-data associated with each user is only in the > jvm > where the person is connected. The live stream is pushed to the subscribers just like what Remote SharedObject does so if configured properly I believe it can be clustered by TC. But I doubt that this is practically realistic because (1) The amount of AV data is much bigger than that of RSO. So much more data will be transfered across the nodes. (2) When the amount of data arises, the transfer latency will also arise and the real time requirement of live streaming is compromised. Anyway we can implement it technically and whether it's practical will be decided by the application. -- View this message in context: http://www.nabble.com/Load-balancing-for-live-streams-tf3926799.html#a11155612 Sent from the Red5 - English mailing list archive at Nabble.com. _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
