Red5 Scopes and Cotexts
Scopes and Contexts
From Red5Wiki
Very important concepts to know about when using or developing for Red5 are the notions of 'scope' and 'context'.
To develop any form of functionality for Red5, you must create what is often referred to as an 'application'; applications are the fundamental foundations upon which any useful interaction between a Flash client and the Red5 server can be built. The term 'application', however, comes from Flash Media Server (FMS), Adobe's own software for communicating with Flash clients. Red5 has a slightly more complicated model for dealing with incoming requests from Flash clients to the Red5 server which uses a combination of building blocks to form a kind of emulation of FMS's notion of an 'application'; in short, when you're creating an application in Red5, you're really creating a combination of a WebScope (a type of scope), a Context, and a handler.
Scope
A good way to understand the scope model in Red5 is to think of each scope like a node in a tree, somewhat akin to a directory or file (depending on what type of scope it is) in a traditional filesystem.
The root scope that is common among all applications (all applications can access it) is called 'default'. It is an instance of a special class called GlobalScope. It is intended to provide common resource sharing across applications. In the Red5 model, it is implicit that all scope 'paths' are underneath this scope; it is not to be named directly by the Flash client when the client is connecting to a scope.
Directly beneath the root scope are a set of special scopes, each representing an application that the Red5 server is running. These scopes are called whatever the application's 'context name' is, and each is an instance of a special class called WebScope. Because these scopes share their name with the application's 'context name', it can be quite confusing as to the difference between these and the application's context. Trust, however, that these are two different things. :-)
Beneath each WebScope, things work a little differently. Each WebScope is defined explicitly by whoever is running the Red5 server; each has its own config files and can be considered a separate application, and in order for a new one to be created, one must create a new application directory and config files, etc. Once we start to specify scopes beneath the WebScope, however, things become dynamic; that is to say, scopes are created dynamically (if they haven't already been created) based on the 'scope path' that is being connected to. For example, assuming that no scopes have yet been created for an application whose context path is 'myApp', a Flash client might connect to 'rtmp://red5serverHostname/myApp/aaa/bbb/ccc'. Red5 would check whether 'aaa' existed, and create it if it didn't. It would query 'aaa' to see whether it had a child scope 'bbb', and create that if it didn't exist. It would query 'bbb' to see whether it had a child scope 'ccc', and create that if it didn't exist.
Each of these dynamic scopes beneath each WebScope is called whatever its 'scope path' name is, eg. for the above example, the scopes would have the names 'aaa', 'bbb', and 'ccc'. They can be instances of either Scope classes or BasicScope classes. 'Leaf nodes', ie. those that do not have any child scopes, are always BasicScope's. 'Non-leaf nodes' are always Scope's. Any scope can provide functionality to a Flash client, however, the scopes that tend to provide actual useful functionality when connected to are the leaf nodes, or BasicScope's. For example, the 'ccc' BasicScope above could provide a live video stream when connected to, or a 'shared object', allowing data to be shared amongst several Flash clients (think: the text in a chatroom application).
To slightly adapt a common phrase, a diagram is worth a thousand words; here's a representation of a typical scope hierarchy on a Red5 server, and the path a Flash client might use to connect to them ('aaa', 'foo', and 'bar' are applications running on the server):
Key: scopeName(scopeClass)
==========================
default(GlobalScope) -> aaa(WebScope) -> bbb(Scope) -> ccc(BasicScope)
(implicit)
/aaa
/bbb
/ccc
-> foo(WebScope) -> chatroom1(Scope) -> videocam1(BroadcastScope)
/foo
/chatroom1
/videocam1
-> videocam2(BroadcastScope)
/videocam2
-> bar(WebScope) -> game1(Scope) -> level1(SharedObjectScope)
/bar
/game1
/level1
-> level2(SharedObjectScope)
/level2
-> game2(Scope) -> level1(SharedObjectScope)
/game2
/level1
-> level2(SharedObjectScope)
/level2
-> level3(SharedObjectScope)
/level3
Example connection paths:
/aaa/bbb/ccc
/foo/chatroom1/videocam2
/bar/game2/level3
Of course, BasicScope's can be and are extended to provide extra functionality as needed by the application containing them; two custom classes that extend BasicScope are pre-defined in Red5; BroadcastScope (video/audio data streams, etc.) and SharedObjectScope (shared data between clients; text, images, etc.)
Context
Each application in Red5 has exactly one context associated with it. The context class associated with the scope implements the interface IContext. The context object for an application is closely associated with the Java Spring framework, and provides functionality such as mapping a 'scope path' to the scope object itself, and providing application code with various services. As each application only ever has one context, and one WebScope, an application's WebScope name is also commonly referred to as its 'context path'; they're effectively synonymous, confusingly.
In code, an application's (or WebScope's) associated IContext object can be accessed by calling IScope.getContext(), where IScope is an object representing the current scope the code is running in. The pre-defined class in Red5 that provides a basic context implementation is unsurprisingly called Context.
Handler
So, we have a system of scopes that can be used to get an idea of what the Flash client wants to connect to, and a context that can be used to map requests to the scopes and provide services to the application code... what code? The code in the handler.
The handler is basically the implementation of the main functionality of a Red5 application. It implements methods that are called when a client connects to or disconnects from the application. It also implements methods that can be used for remote procedure calls (RPC) by the Flash client (as a very simple example, one could implement an 'add' RPC that took two number arguments, added them together, and returned the result to the client). As described above, the initial 'entry point' for every application is its WebScope class. Red5 needs to be able to call various methods on this class when a client connects to the application. For this reason, the application's handler must implement the IScopeHandler interface, which defined some methods Red5 needs to be able to call.
Handlers created by those developing Red5 applications will often extend either the ApplicationAdapter class or the MultiThreadedApplicationAdapter class, because these two classes are pre-defined by Red5, and they already implement a lot of basic handler functionality, and implement the required IScopeHandler interface.
So-called 'video on-demand', a feature introduced by Adobe in Flash Media Server, is supported by Red5. This functionality is built in to Red5 and does not need to be implemented by the application's handler. Read more about video on-demand (VOD) here .