Scopes and Contexts
From Red5Wiki
<!-- start content -->
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
.
分享到:
相关推荐
Laravel开发-laravel-scopes .zip
Laravel开发-laravel-scopes Laravel的查询生成器的方便范围。
Laravel开发-eloquent-scopes 雄辩(laravel)查询生成器的方便范围。
MATLAB课件:ch4_functions_and_scopes.pdf
Laravel开发-laravel-eloquent-scopes 雄辩的一般范围
NULL 博文链接:https://moshow.iteye.com/blog/1607598
Python is a free open-source language and environment that has tremendous ...Chapter 12 Namespaces, Scopes and Modules Chapter 13 Input and Output Chapter 14 Testing Chapter 15 Comprehensive Examples
• Explore Swift s object-oriented concepts: variables and functions, scopes and namespaces, object types and instances • Become familiar with built-in Swift types such as numbers, strings, ranges, ...
In Pro CDI 2 in Java EE 8, use CDI and the CDI 2.0 to automatically manage the life cycle of your enterprise Java, Java EE, or Jakarta EE application’s beans using predefined scopes and define custom...
Chapter 4 Scopes and Symbol Tables Chapter 5 Interpretation Chapter 6 Type Checking Chapter 7 Intermediate-CodeGeneration Chapter 8 Machine-CodeGeneration Chapter 9 Register Allocation Chapter 10 ...
Desigo CC手册-08_Scopes_BA_CN(审视)
Explore Swift’s object-oriented concepts: variables and functions, scopes and namespaces, object types and instances Become familiar with built-in Swift types such as numbers, strings, ranges, tuples...
Explore Swift’s object-oriented concepts: variables and functions, scopes and namespaces, object types and instances Become familiar with built-in Swift types such as numbers, strings, ranges, tuples...
Explore Swift’s object-oriented concepts: variables and functions, scopes and namespaces, object types and instances Become familiar with built-in Swift types such as numbers, strings, ranges, tuples...
upfc for students..feel free to run it and see the scopes and analyse the results
scopes.js是该库的主要模块版本:1.1.0先决条件符合ECAScript 2015的Javascript环境安装NPM软件包-`npm install prop-scopes'测验存储库包含脚本testbed.js ,该脚本包含用于测试范围库功能的可选功能列表。...
github-oauth-scopes 用于处理github宣誓范围的实用程序 var ghScopes = require ( 'github-oath-scopes' ) ; ghScopes . isValid ( 'repo' ) ; // true ghScopes . isValid ( 'bad_scope' ) ; // false ghScopes ...
Once you understand the tenets of Ruby, including the object model, scopes, and singleton classes, you're on your way to applying metaprogramming both in your daily work assignments and in your fun, ...