I'm not streaming live data but stored flv movies. And the problem then appears when a lot of people access the file at the same time but all at a different position (in time).
On 6/17/07, Steven Gong <[EMAIL PROTECTED]> wrote:
Orion, On 6/17/07, Orion Letizi <[EMAIL PROTECTED]> wrote: > > > 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). Yep, that's true if the VOD streaming is pulled by the client. But as we also need to track the client buffer, we are using a scheduled task to push the VOD content to the client. I was thinking of sharing the connection buffer across the cluster if the connection is of type RTMPTConnection. When the connection is of type RTMPT, we use a buffer for each connection to save the packets that will be sent to the client. These packets includes AV packets, RSO packets, invocation result etc. When the client's request is distributed to one of the node, the server retrieves packets in the buffer and sends to the client. So all kinds of services, regardless of VOD, Live or RSO, can be shared without the need to share the whole connection or stream objects. What do you think? 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 > -- I cannot tell why this heart languishes in silence. It is for small needs it never asks, or knows or remembers. -- Tagore Best Regards Steven Gong _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
