Action Message Format (AMF) is a binary format used to serialize objects graphs such ActionScript objects and XML, or send messages between an Adobe Flash client and a remote service, usually a Flash Media Server or third party alternatives.
The format is often used in conjunction with Adobe's RTMP to establish connections and control commands for the delivery of streaming media. In this case, the AMF data is encapsulated in a chunk which has a header which defines things as the message length and type (whether it is a "ping", "command" or media data).
|
Contents
|
AMF was introduced with Flash Player 6, and this version is referred to as AMF0. It was unchanged until the release of Flash Player 9 and ActionScript 3.0, when new data types and language features prompted an update, called AMF3.[1]
Adobe Systems published the AMF binary data protocol specification[2] on December 13, 2007 and announced that it will support the developer community to make this protocol available for every major server platform.
The format specifies the various data types that can be used to encode data. Adobe states that AMF is mainly used to represent object graphs that include named properties in the form of key value pairs, where the keys are encoded as strings and the values can be of any data type such as strings or numbers as well as arrays and other objects. XML is supported as a native type. Each type is denoted by a single byte preceding the actual data. The values of that byte is as below (for AMF0):
AMF Objects begin with a (0x03) followed by a set of key value pairs and end with a (0x09). Keys are encoded as strings with the (0x02) 'type-definition' byte being implied (not included in the message). Values can be of any type including other objects and whole object graphs can be serialised in this way. Both object keys and strings are preceded by 2 bytes denoting their length in number of bytes which means that a string will have a total of 3 bytes acting as a header. Null types only contain their type-definition (0x05). Numbers are encoded as double precision floating point and are composed of 8 bytes.
Although, strictly speaking, AMF is only a data encoding format, it is usually found encapsulated in a RTMP Message or Flex RPC call. An example of the former can be found below (it is the "_result" message returned in response to the "connect" command sent from the flash client):
| Hex Code | ASCII |
|---|---|
| 03 00 00 00 00 01 05 14 00 00 00 00 02 00 07 5F 72 65 73 75 6C 74 00 3F F0 00 00 00 00 00 00 03 00 06 66 6D 73 56 65 72 02 00 0E 46 4D 53 2F 33 2C 35 2C 35 2C 32 30 30 34 00 0C 63 61 70 61 62 69 6C 69 74 69 65 73 00 40 3F 00 00 00 00 00 00 00 04 6D 6F 64 65 00 3F F0 00 00 00 00 00 00 00 00 09 03 00 05 6C 65 76 65 6C 02 00 06 73 74 61 74 75 73 00 04 63 6F 64 65 02 00 1D 4E 65 74 43 6F 6E 6E 65 63 74 69 6F 6E 2E 43 6F 6E 6E 65 63 74 2E 53 75 63 63 65 73 73 00 0B 64 65 73 63 72 69 70 74 69 6F 6E 02 00 15 43 6F 6E 6E 65 63 74 69 6F 6E 20 73 75 63 63 65 65 64 65 64 2E 00 04 64 61 74 61 08 00 00 00 00 00 07 76 65 72 73 69 6F 6E 02 00 0A 33 2C 35 2C 35 2C 32 30 30 34 00 00 09 00 08 63 6C 69 65 6E 74 69 64 00 41 D7 9B 78 7C C0 00 00 00 0E 6F 62 6A 65 63 74 45 6E 63 6F 64 69 6E 67 00 40 08 00 00 00 00 00 00 00 00 09 | . . . . . . . . . . . . . . . _ r e s u l t . ? . . . . . . . . . f m s V e r . . . F M S / 3 , 5 , 5 , 2 0 0 4 . . c a p a b i l i t i e s . @ ? . . . . . . . . m o d e . . . . . . . . . . . . . . l e v e l . . .s t a t u s . . . c o d e . . . N e t C o n n e c t i o n . C o n n e c t . S u c c e s s . . d e s c r i p t i o n . . . C o n n e c t i o n su c c e e d e d . . d a t a . . . . . . . version . . . 3 , 5 , 5 , 2 0 0 4 . . . . . . c l i e n t i d . . . . . . . . . . . o b j e c t E n c o d i n g . @ . . . . . . . . . . |
legend: object start/end object keys object values array
The AMF message starts with a 0x03 which denotes an RTMP packet with Header Type of 0, so we expect 12 bytes to follow. It is of Message Type 0x14 which denotes a command in the form of a string of value "_result" and two serialized objects as arguments. The message can be decoded as follows:
(command) “_result”
(transaction id) 1
(value)
[1] { fmsVer: "FMS/3,5,5,2004"
capabilities: 31.0
mode: 1.0 },
[2] { level: “status”,
code: “NetConnection.Connect.Succeeded",
description: “Connection succeeded”,
data: (array) {
version: “3,5,5,2004” },
clientId: 1584259571.0,
objectEncoding: 3.0 }
Here we can see an array (in turquoise) as a value of the 'data' key which has one member. We can see the objectEncoding value to be 3. This means that subsequent messages are going to be sent with the 0x11 message type which will imply an AMF3 encoding.
The newer version of the protocol specifies some changes in the data types above. A message containing AMF3 encoded data has the message type byte set to 0x11 instead of 0x14 and will contain an extra 0x00 byte at the end of the header. AMF3 is in fact encapsulated within AMF0 and it is possible that a message of type AMF3 to contain no such data. The data type markers are as follows:
The various AMF Protocols are supported by many server-side languages and technologies, in the form of libraries and services that must be installed and integrated by the application developer.
Platforms:
Frameworks:
|
||||||||||||||||||||||
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)