This post is also available in: Russian
This article opens a series of publications dedicated to the development of C++ plug-ins for Flash Media Server. Not that we are going to describe all FMS features, but rather to compensate for certain lack of information on C++ plug-in development on vendors’ sites.
The series will cover the following topics:
Part 1: Conceptual overview of FMS architecture
Part 2: RTMP URL tokenization based on authorization plug-in
Part 3: Load balancing using access plug-in
Part 1. Conceptual Overview of FMS Architecture
Introduction
The main purpose of Adobe Flash Media Server (FMS) is to deliver multimedia content to users. However, FMS also features quite a handy tool for building business logic of real-time multi-user applications. FMS offers a built-in scripting language Server Side ActionScript (SSAS) (it is bare JavaScript though). SSAS has almost everything you need to develop applications (except built-in database support).
Still, if you want to monitor more closely what is happening inside the server, to detect and handle events, to monitor the load on various server components, monitor inbound connections or gain access to content located on any distributed file system, you can extend server functionality by creating custom modules or plug-ins.
Architecture
FMS is based on the client-server architecture. By default, any installation includes at least 4 processes shown in Fig. 1:
- fmsmaster
- edge
- core
- admin
When FMS starts, fmsmaster is launched. This process is mainly used to start or stop the core processes when necessary. You can run only one fmsmaster and you can not manage it or configure it. Client connections are never handled by this process.
All inbound client connections are initially captured by the edge process, regardless of FMS configuring scheme (EDGE / ORIGIN). Here the client connection can be subject to the access plug-in, if any. For more detail on distribution of inbound connections exemplified by load balancing, please follow our publications.
After that, the client connections are handed over to the core processes running SSAS applications, authentication plug-in(s) and the file plugin.
The admin process provides access to the Administration API which allows you to monitor, configure and manage FMS.
Types of FMS Plug-ins
For plug-in creation, Adobe has provided a special C++ SDK, enabling 3 types of plug-ins as extensions:
The access plugin is another level of FMS security, processing inbound connections before they reach SSAS applications. The FMS server can run only one access plug-in! The main purpose of this type of plug-in is to accept or reject incoming connections based on some criteria: statistics data, authorization request to an external entity, etc. Also, the access plug-in allows you to set the level of access to content. For resource-intensive services, perhaps the most critical feature is that access plug-in can link incoming connections to the specific core processes. This balances the server load and optimizes resource utilization. For more detail on load balancing, please follow our next publications.
The authorization plug-in allows you to manage events that occur within the core processes. It can control inbound connections, manage content access, map between the logical and physical path to the content. Moreover, you can build a sophisticated business logic to manage subscription-based access to content, and accumulate statistics on content use. Also, you can asynchronously call SSAS application methods, disconnect clients from the application, etc. You may have several such plug-ins, and they will all handle FMS events in alphabetical order.
The file plug-in allows you to organize asynchronous access to content located at any distributed file system using any protocol. Also, you can control content caching based on your own rules. Only one file plug-in can be installed.
Well, this rounds off our short overview of FMS concepts and architecture. For more details, please refer to the FMS documentation: