Red5 is an open source Flash server. We are currently working with the Red 5 team to cluster the servers with Terracotta.

Red5 site: http://www.osflash.org/red5

Steven Gong's notes on goals, strategy, and architecture: http://codingspace.blogspot.com/
More architecture documentation: http://jira.red5.org/confluence/display/CLU/Edge+Origin+Solution+on+Terracotta

News

July 26, 2007: Steve Harris, Ari Zilka, and Orion Letizi had an architecture brainstorming session.

Our main idea is that, in the first implementation, it makes sense (according to Steven Gong's original proposal) to use Terracotta to cluster the stream data, with the ultimate goal to be to use Terracotta to cluster the metadata about the streams, connections, and the shape of the cluster, but to replace the stream transport mechanism between the origin and the edges and between edges with more efficient implementations.

Shared Flash Objects

Shared Flash object data can be kept in a Terracotta-shared data structure. We have a couple of prototype versions of this done, the latest being Steven Gong's implementation mentioned below. Terracotta is a perfect fit for this purpose.

Connection State

Data structures that represent connection state can be clustered with Terracotta. This will provide a global view on the state of all connections to all of the edge servers.

Cluster Shape/Membership

Keeping a data structure that represents the state of the cluster (i.e., what origin servers are present and active and what edge servers are present and active) in Terracotta can provide a global view on the current state of the cluster.

Load Balancing

Load balancing based on URL of the stream isn't as flexible as load balancing based on hotness of the stream and hotness of each edge. If you keep hotness data in a Terracotta shared data structure, you can use a more sophisticated load-balancing algorithm.

Getting Stream Data to Edges

The first pass implementation can use Terracotta as the transport mechanism to move stream data around the cluster. This is probably the simplest way to implement the solution.

We used some made-up terminology that I will continue using here. For the purposes of this discussion, we called streams that were completely stored on disk "static." We called streams that were generated by an external source (a connected flash client recording a video stream, for example) "dynamic."

We assumed that "static" streams were stored on disk at the origins. In the first-pass implementation, it would be relatively simple to move "static" streams from the origins out to the edges by loading them into a data structure shared by Terracotta. If an edge server needs to send content to a connected flash client, it should be able to read from that same Terracotta-shared data structure.

We assumed that "dynamic" streams come from connected flash clients. Again, in the first-pass implementation, it would be simplest for the edge receiving the incoming stream data from the flash client to add it to a Terracotta-shared data structure. Edges that need to send that incoming content back out to other flash clients should be able to read from the Terracotta-shared data structure in the same way they read static streams.

In a final implementation, the stream data, both "static" and "dynamic," may not be kept in Terracotta-shared data structures. It might be more efficient for streams to be served (either from origin to edge or from edge to edge) directly. But, it probably always makes sense to keep metadata about where the stream data lives in a Terracotta-shared data structure.

July 25, 2007: Steven Gong has a preview of the clusterable shared object code in a Red5 branch. Here's his description:

Hi all,
I have just committed a preview version of Remote SharedObject clustering code to SVN on branch:

http://svn1.cvsdude.com/osflash/red5/java/server/branches/clustering

This implementation is based on the idea to cluster the whole scope tree without explicit Terracotta hack to the code base. Great thanks to original work from Terracotta buddies, especially Orion Letizi. There're still bugs though (some life-cycle issues of Scope and some init issues of SO) but you can see the RSO clustering works on two nodes.

How to play around with it on Eclipse?

• Download and install the latest version of Terracotta Eclipse plugin. (2.4.0)
• Check out the branch from SVN and create the Red5 TC application. (Using Standalone)
• Start the TC server
• Start the Red5 TC application (Node 1). The port is 1935.
• Start the Red5 TC application again (Node 2). The port is 1935+1=1936.
• Run BallControl demo to connect to 1935.
• Run another BallControl demo to connect to 1936.
• Move the ball and you will see it moving on another BallControl window and vice versa.

Welcome to any feedbacks. Thanks ahead!

–
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

June 29, 2007: Red5 and Terracotta POC works!
On Friday, June 29th, Tim Eck and Orion Letizi spent some time getting a Red5 and Terracotta POC working. Instead of trying to get everything in the Scope tree clustered, we took a different approach: we refactored the SharedObjectScope so that there is a separate data structure that contains the shared object data. Then, we clustered that separate data structure.

June 29th, 2007: I (Orion) spent some time getting the Scope tree shared in Terracotta. While I was able to get the data into Terracotta, there are initialization issues with this naive and brute force approach that warrant a more finessed approach.