Well that currently hard to say because the server died and didn't leave any
logs (he couldn't access the filesystem). I'm almost finished with another
part of the Red5 app I'm building after that I will post an url of a movie.
If everyone can access that movie maybe I can see the amount of connections
and post the data here.

I run Red5 with ant, is there a way I can store the logs?

On 6/18/07, Steven Gong <[EMAIL PROTECTED]> wrote:



On 6/18/07, Martijn van Beek <[EMAIL PROTECTED]> wrote:
>
> 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).


That IS a problem which might be solved by a cache system. FMS uses cache
on Edge servers.

Martijn, could you please give more data about this issue? How many
concurrent accesses will become a bottleneck for the I/O reading of FLV?

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
>
>


--
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

Reply via email to