Thursday, June 28, 2007
How to detect whether a PCI device is PCI-E
Work through the Capability List of PCI configuration space to find the PCIE capability id 0x10. If the PCIE capability id exists, the device is PCIE.
Saturday, June 9, 2007
Red5 Clustering with Terracotta -- Roadmap
The clustering effort is planned in several steps.
1. Implement clustered Edges with one Origin. The Edges run on Terracotta and behind a generic http load-balancer. This needs some minor changes to the current code base and the design of a new Edge-Origin protocol. Only RTMPT is supported.
2. Add the support of independent multiple Origins and load-balancing policy in Edges.
3. Cluster the Origins with Terracotta.
1. Implement clustered Edges with one Origin. The Edges run on Terracotta and behind a generic http load-balancer. This needs some minor changes to the current code base and the design of a new Edge-Origin protocol. Only RTMPT is supported.
2. Add the support of independent multiple Origins and load-balancing policy in Edges.
3. Cluster the Origins with Terracotta.
Red5 Clustering with Terracotta -- Goal
The clustering goal of Red5 server is:
1. Scalable -- The server capacity is enlarged when more hardwares are added.
2. Edge Fail-over -- Client will not be aware of Edge failures.
3. Origin Fail-over -- Client needs no reconnection when one Origin fails.
4. Load-balancing -- Automatic or Manual load balancing configuration so that connections are properly distributed among Origins.
5. Real Origin clustering to support mass user-based chat/gaming/video conference.
1. Scalable -- The server capacity is enlarged when more hardwares are added.
2. Edge Fail-over -- Client will not be aware of Edge failures.
3. Origin Fail-over -- Client needs no reconnection when one Origin fails.
4. Load-balancing -- Automatic or Manual load balancing configuration so that connections are properly distributed among Origins.
5. Real Origin clustering to support mass user-based chat/gaming/video conference.
Red5 Clustering with Terracotta -- FMS Clustering Overview
I've been working on Red5 clustering recently. Thanks to Terracotta and the guys from Terracotta Team (very nice guys), the clustering effort is possible.
Well, it's still tough actually. The server is designed without any consideration of how it will be clustered in the future. It might run on a single node smoothly but it's not true when being scaled out.
We are lucky though because we want to be, in the first place, an alternative to Adobe's Flash Media Server (FMS). Let's take a look at how FMS provides the clustering solution for the server. It's said that one Chinese gaming arena vendor, which uses FMS, could support up to 100,000 concurrent users.
FMS cluster is surely not running on Terracotta. It uses two-layer solution. The first layer, which is balanced behind a load-balancer, is called Edge Servers. The Edge Servers maintain the connections from the FP clients and authenticate them if needed. The actually work is done on the second layer -- Origin Server. The Edge Servers forward the RTMP packets to Origin Server. The latter properly handles those requests and sends back the result. There's only one connection between an Edge and an Origin. Multiple client to Edge connections are multiplexed in this connection.
The concern is separated between Edge and Origin. The connection maintenance, which might consume a lot of resources, is on Edge's side and Edges are clustered. The Origin only needs to maintain the connections with Edge Servers and the amount is small. The Origins are not clustered though, at least in the FMS middleware. (Guess why? It's complex.:P)
Many existing applications are be deployed on this framework without any problem as long as the Live streaming (video conference) and the Remote SharedObject involve a small amount of concurrent users as groups. There could be a great number of groups of course and the groups can be scattered across the independent Origins.
Above is my observation of FMS's stuff, correct me if I am wrong.
Well, it's still tough actually. The server is designed without any consideration of how it will be clustered in the future. It might run on a single node smoothly but it's not true when being scaled out.
We are lucky though because we want to be, in the first place, an alternative to Adobe's Flash Media Server (FMS). Let's take a look at how FMS provides the clustering solution for the server. It's said that one Chinese gaming arena vendor, which uses FMS, could support up to 100,000 concurrent users.
FMS cluster is surely not running on Terracotta. It uses two-layer solution. The first layer, which is balanced behind a load-balancer, is called Edge Servers. The Edge Servers maintain the connections from the FP clients and authenticate them if needed. The actually work is done on the second layer -- Origin Server. The Edge Servers forward the RTMP packets to Origin Server. The latter properly handles those requests and sends back the result. There's only one connection between an Edge and an Origin. Multiple client to Edge connections are multiplexed in this connection.
The concern is separated between Edge and Origin. The connection maintenance, which might consume a lot of resources, is on Edge's side and Edges are clustered. The Origin only needs to maintain the connections with Edge Servers and the amount is small. The Origins are not clustered though, at least in the FMS middleware. (Guess why? It's complex.:P)
Many existing applications are be deployed on this framework without any problem as long as the Live streaming (video conference) and the Remote SharedObject involve a small amount of concurrent users as groups. There could be a great number of groups of course and the groups can be scattered across the independent Origins.
Above is my observation of FMS's stuff, correct me if I am wrong.
Subscribe to:
Posts (Atom)