某些 Creative Cloud 应用程序、服务和功能在中国不可用。
Many companies use statistics from the access log to bill customers. If your programming includes live events or 24/7 programming, the events you use to calculate billing might not occur within a billing cycle. To solve this problem, you can enable checkpoint events. Checkpoint events log bytes periodically during an event. The following are available as checkpoint events: connect-continue, play-continue, and publish-continue.
You must enable checkpoint events at the server level in the Server.xml file. You can disable checkpoints at the vhost and application level in the Vhost.xml and Application.xml files. You can also override the logging interval at the vhost and application levels. For more information, see the comments in the XML files located in the rootinstall/conf folder.
Open the rootinstall/conf/Server.xml file in a text editor.
Locate the Root/Server/Logging/Checkpoints element:
<Checkpoints enable="false"> <CheckInterval>60</CheckInterval> <LogInterval>3600</LogInterval> </Checkpoints>Set the Checkpoints enable attribute to true, like this: <Checkpoints enable="true">.
You can optionally set values for the CheckInterval and LogInterval elements to indicate how often the server should check for and log events.
Save and validate the file.
Restart the server.
-
Set the USERS.HTTPCOMMAND_ALLOW parameter to a comma-delimited list of APIs, and restart the server. The default value is ping. For more information, see Allow (HTTPCommands).
To play back streams and obtain data from shared objects, the Administration Console must make a special debugging connection to the server. By default, the server does not allow this connection.
IPv6 (Internet Protocol version 6) is a new version of Internet Protocol that supports 128-bit addresses. The current version of Internet Protocol, IPv4, supports 32-bit addresses. IPv6 alleviates the address shortage problem on the Internet. A system that only runs IPv6 can't communicate with a system that only runs IPv4.
By default, Adobe Media Server runs in IPv4 mode, even if the operating system is configured for IPv6. When Adobe Media Server runs in IPv6 mode, hostnames specified in Adaptor.xml are resolved to IPv4 and IPv6 addresses.
Note:
In Red Hat® Linux systems, you must update the NETWORKING_IPV6 value in /etc/sysconfig/network when installing or uninstalling IPv6.
IPv6 is embedded in all operating systems that the server supports. You may need to activate IPv6 on the interfaces. For more information, see the operating system’s Help.
Wherever a numeric IPv6 address is used in a client-side script, server-side script, or in the server configuration files, enclose it in brackets:
rtmp://[fd5e:624b:4c18:ffff:0:5efe:10.133.128.108]:1935/streamtest
rtmp://[fe80::204:23ff:fe14:da1c%4]:1935/streamtest
Note:
It’s a good idea to register the RTMP, RTMPS, and RTMPE protocols with a network services database and use a service name (or decimal port number, if necessary) in the server configuration files.
When the server starts, it logs available stack configuration, host name, and all available IP addresses for the host in the master.xx.log, edge.xx.log, and admin.xx.log files (located in the rootinstall/logs/ directory). The following x-comment fields from a sample edge log file indicate that the IPv6 stack and the IPv4 stack are available, and that the server host has dual addresses and is listening on both interfaces:
AMS detected IPv6 protocol stack! AMS config <NetworkingIPv6 enable=true> AMS running in IPv6 protocol stack mode! Host: amsqewin2k3-02 IPv4: 10.133.192.42 IPv6: fe80::204:23ff:fe14:da1c%4 Listener started ( _defaultRoot__? ) : 19350/v6 Listener started ( _defaultRoot__? ) : 19350/v4 Listener started ( _defaultRoot__? ) : 1935/v6 Listener started ( _defaultRoot__? ) : 1935/v4
On Red Hat Linux, the edge logs display only the highest IP version the socket listeners are using, even if the socket listeners accept connections over both IPv4 and IPv6. In the previous example, only the v6 entries would be displayed.
On IPv6-enabled Linux, if you are using an host name that resolves to IPv4 host name with an RTMPT or RTMPTE connection, configure the Adaptor.xml appropriately to resolve connections quickly. See HTTPIdent2.
You can define properties for the server-side Application object in the server’s Application.xml configuration files. If you define properties in the default Application.xml file, the properties are available for all applications on a virtual host. If you define properties in an Application.xml file in an application folder, the properties are available only for that application.
To define a property, create an XML tag in the ScriptEngine section of the Application.xml file. The property name corresponds to the tag’s name, and the property value corresponds to the tag’s contents.
For example, the following XML fragment defines the properties user_name and dept_name, with the values jdoe and engineering, respectively:
<Application> <ScriptEngine> <config> <user_name>jdoe</user_name> <dept_name>engineering</dept_name> </config> </ScriptEngine> </Application>
application.config.prop_name application.config["prop_name"]
Note:
The properties you define are accessible from application.config.property, not from application.property.
trace("I am " + application.config.user_name + " and I work in the " + application.config.dept_name + " department.");
trace("I am " + application.config["user_name"] + " and I work in the " + application.config["dept_name"] + " department.");
I am jdoe and I work in the engineering department.
You can also use environment variables and symbols you define in the substitution.xml file. For example, assume that the environment variable COMPUTERNAME is equal to jsmith01, and you have defined a symbol named DEPT in the substitution.xml file:
<Root> <Symbols> <DEPT>Engineering</DEPT> </Symbols> </Root>
<Application>
<ScriptEngine>
<config>
<compName>${%COMPUTERNAME%}</compName>
<dept>${DEPT}</dept>
</config>
</ScriptEngine>
</Application>
trace("My computer's name is: " + application.config.compName);
trace("My department is: " + application.config.dept);
My computer's name is: jsmith01 My department is: Engineering
Note:
Server-side ActionScript trace()statements display in the Live Log panel of the Administration Console.
The server can detect a client’s bandwidth in the core server code (called native bandwidth detection), or in a server-side script (called script-based bandwidth detection). Native bandwidth detection is faster than script-based because the core server code is written in C and C++. Also, with native bandwidth detection, if a client connects through edge servers, the outermost edge server detects the bandwidth, which results in more accurate data. Native bandwidth detection is enabled and configured by default.
The server detects bandwidth by sending a series of data chunks to the client, each larger than the last. If desired, you can configure the size of the data chunks, the rate at which they’re sent, and the amount of time the server sends data to the client. For more information about detecting bandwidth in an application, see the Developer Guide.
-
Element
Description
BandwidthDetection
Set the enabled attribute to "true" or "false" to turn this feature on or off.
MaxRate
The maximum rate in Kbps that the server sends data to the client. The default value is -1, which sends the data at whatever rate is necessary to measure bandwidth.
DataSize
The amount of data in bytes that the server sends to the client. To detect the client’s bandwidth, the server attempts to send a series of random blocks of data to the client, each time sending this much more data. For example, x bytes are sent, followed by 2x bytes, followed by 3x bytes, and so on until MaxWait time has elapsed.
MaxWait
The number of seconds the server sends data to the client. Increasing this number provides a more accurate bandwidth figure, but it also forces the client to wait longer.