SWF FILE STRUCTURE
Introduction
When saying Flash,
we can mean absolutely different things even within the bounds of
web-technology terms. Not to get confused, I'll use the following terms:
So,
when loading a web page with flash animation, the following processes
take place: web-browser detects an embedded flash animation in an HTML
markup, creates and object of flash-player and indicate what file needs
to be displayed. Flash player loads SWF file and begins to display it if
possible. Due to this principle of work, flash player can display so
called preloaders, reproduce streaming audio and video (for example,
YouTube) without loading SWF fully.
SWF structure
File
format is described in "SWF file format specification" document, which
can be downloaded at Adobe.com. Documentation is usually issued some
months after the release of a new version of flash player. At the
moment, flash player v.10 is already released, but specification
document is not renewed and contains specification of version 9. One can
find specifications about almost everything I explain here, but the
matter is that "almost", but not everything :)
Basic
structure of SWF doesn't depend on version, that's why SWF always has
Header+Body structure. Body consists of records which are called tags in
specification.
To describe data structure, I'll use Object Pascal syntax.
Header
Header contains main information about SWF. It can be described in this way:TSWFHeader = packed record
SIGN: array [0..2] of AnsiChar;
Version: byte;
FileSize: LongWord;
MovieRect: TRect;
FPS: word;
FramesCount: word;
end;
SWF compression
To reduce file size, Macromedia has used two approaches.The first one consists of that bit-by-bit compression method is used for saving numbers. It looks like this. Let's presume we need to save a size of rectangle, i.e. four numbers of integer type. At a simple record it will be 4 * 4 bytes = 16 bytes. At recording to SWF, the number of bits needed for coding the largest value is recorded to the first 5 bit, and then these 4 values in bit representation with a specified bit length. For example, it's necessary to save coordinates (0,0 – 100, 100) or in twips (0,0 – 2000,2000). In bit representation number 2000 = 11111010000 (11 bit + 1 for a sign). We have (5 + 4 * 12) / 8 = 7 byte (almost 2 times less). This approach leads to the fact that some identical tags can have different size. It also applies to Header.
The second approach is using ZLib compression method both for the whole SWF and for separate tags.
When a file is compressed, first three parameters of a Header (8 bytes) are not compressed, but the rest are compressed. This explains why it's impossible to read an SWF header only with one read method.
LOG FILE STRUCTURE
Definition
The
log file template contains information about which text files are to be
analyzed in which form.
Structure
General Settings for the Monitored Log Files
The following parameters of the log file template
apply to all log files that fulfill the conditions for DIRECTORY
and FILENAME:
|
LOGFILE_TEMPLATE
|
|
Key word for the agent; opens a search
area
|
|
DIRECTORY="<directory>"
(required parameter)
|
|
Directory that contains the log
file
|
|
FILENAME="<file
name>"
(required parameter)
|
|
Name of the log file; wildcards are
permissible
|
|
MONITOR_CONTEXT="<context
name>"
|
|
Name of the monitoring context to which the
log file agent writes the results of the monitoring; by default, this is the
context Files_of_<Hostname>. Regardless of whether or not
you set this parameter, the MTE class of the monitoring context is always
CcmsFileMonitoring. By specifying this MTE class,
you can define a rule-based monitor that contains the subtrees for all
monitored log files.
In this way you can, for example, store
different components in different contexts to further group the results. Like
the PREFIX parameter (see below), this
function allows you to differentiate between the different monitored log
files, but provides, unlike PREFIX, an additional hierarchical
level to group the monitored files. Use this parameter only if you require
this additional hierarchical level.
|
|
IGNORE_CASE=[0,1]
(Default = 0)
|
|
By default, all search patterns are case
sensitive (0). If upper and lower case are to be
disregarded, set IGNORE_CASE=1.
|
|
MONITOR_NEWEST_FILES=<number>
(Default = 20)
|
|
Maximum number of files that is to be
monitored; if the number of files whose names fulfill the search criteria
exceeds this number, exactly <number> files with the newest change
time are monitored.
This means that different files are monitored
over time. If a file is removed from monitoring because other files have a
newer change date, its monitoring tree is deleted, and its alerts are reset.
The maximum value for number is also 20, to avoid storing an
unnecessarily large quantity of data in the monitoring
architecture.
|
|
RESCANFROMBEGIN=[0,1]
(Default = 0)
|
|
Specifies whether each new read operation
reads the log file from the start (1) or only the lines that have been
added since the log file agent last read the file (0)
|
|
MONITOR_FILESIZE_KB=<file
size[KB]>
(Default: FileSize is not created)
|
|
Value < 0: FileSize
is not created.
Value = 0: Size of the log file in KB is
monitored in the node FileSize
Value > 0: The size of the log file in KB is
monitored; if the file size exceeds the value, an alert is
generated
|
|
PREFIX="<character string>"
|
|
Appears before the MTE nodes; allows you to
differentiate between different log files with different paths, but the same
name
|
|
SHOWNEWLINES=[0,1]
(Default = 0)
|
|
Value=1: The Alert Monitor creates the
subnode Newlines; that is, the number of lines
created per minute is
reported
Value=0: Newlines is not
created
|
|
ANALYZEMETHOD="<method
name>"
(Default: no method)
|
|
Analysis method that is assigned to the
alert
|
|
MONITOR_LAST_FILE_MODIF=[0,1]
(Default = 0)
|
|
Specifies whether a separate performance node
File Time Stamp is to be created, which then monitors the last change
time point of the log files (1), or whether the last change time
point is not to be monitored (0)
|
|
MTE_CLASS="<MTE
class>"
(Default: CcmsFile<file
name>)
|
|
MTE class of the monitoring object that
contains the attributes specified above; the MTE class of the monitoring
objects therefore depends on the name of the monitored log file
|
|
CHECK_EXISTENCE_ONLY=[0,1]
(Default = 0)
|
|
Specifies whether the system is to check only
for the existence of the log files (1). In this case, all parameters for
monitoring and for search patterns (see below) are ignored.
|
Monitored Search Pattern in the Monitored Log Files
You
can specify multiple search patterns to be monitored for each of the log files
that fulfils the conditions for DIRECTORY and FILENAME. When doing this, enter a
number <x> for each search pattern in the
parameter suffix of the following parameters. Begin with the number
0.
|
PATTERN_<x>="<character
string>"
(PATTERN_0 is required)
|
|
Search pattern in the log file (case
sensitive; wildcards are not allowed)
|
|
MESSAGEID_<x>="<message
ID>"
(MESSAGEID_0 is required)
|
|
Message number that is assigned to the
alert
|
|
VALUE_<x>=[RED,YELLOW,GREEN]
Default =
YELLOW
|
|
Color of the alert in the monitoring
architecture
|
|
SEVERITY_<x>=[0...255]
Default =
0
|
|
Severity of the alert
|
|
MESSAGECLASS_<x>="<message
class>"
Default =
SAP-T100
|
|
Message class
|
|
CMP_FROM_BEGIN_<x>=[0,1]
Default =
0
|
|
Value=1: The line must begin with the search
pattern (better performance)
Value=0: The search pattern can be in any
position in the line
|
Search Pattern to be Output in the Monitored Log Files
You
can use the parameters explained above to monitor log files for search
patterns to which an alert is to be assigned (such as the search pattern
Error). This function is not ideal for
displaying search patterns to which no alert is to be assigned (such as
version or date information). Only one log attribute is available in the Alert
Monitor for all monitored search patterns, meaning that only one line is
displayed even in the case of multiple search patterns.
There
is therefore a second way in which you can monitor log files for search
patterns. If a search pattern of this type is found, the Alert Monitor
displays the corresponding line as the content of a separate text attribute.
You can define the name of the text attribute yourself. If the search pattern
exists at several places in the log file, the system displays the last
position in which it is found.
|
APPL_INFO_<x>="<character
string>"
|
|
Search pattern in the log file (case
sensitive; wildcards are not allowed); if the search pattern is found, the
system displays the line of the log file in which the search pattern was found
in the Alert Monitor
|
|
APPL_INFO_MTE_NAME_<x>="<MTE_Name>"
|
|
Name of the text attribute in which the line
is displayed; the complete node name is INFO[<MTE
name>]
|
·
Note that you
must end the file with a period (.).
·
If parameters
are required, this is highlighted. All other parameters are
optional.
Tidak ada komentar:
Posting Komentar