Action Message Format
Internet media type |
application/octet-stream |
---|---|
Developed by | Adobe Systems |
Type of format | Data exchange format |
Container for | Structured data |
Action Message Format (AMF) is a binary format used to serialize object graphs such as 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 Actionscript 3 language provides classes for encoding and decoding from the AMF format.
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 such as the message length and type (whether it is a "ping", "command" or media data).
Format analysis
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] Flash Player 10 added vector and dictionary data types documented in a revised specification of January 2013.
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.
AMF self-contained packet
The following amf-packet is for transmission of messages outside of defined Adobe/Macromedia containers or transports such as Flash Video or the Real Time Messaging Protocol.
Length | Name | Type | Default |
---|---|---|---|
16 bits | version | uimsbf | 0 or 3 |
16 bits | header-count | uimsbf | 0 |
header-count*56+ bits | header-type-structure | binary | free form |
16 bits | message-count | uimsbf | 1 |
message-count*64+ bits | message-type-structure | binary | free form |
Length | Name | Type | Default |
---|---|---|---|
16 bits | header-name-length | uimsbf | 0 |
header-name-length*8 bits | header-name-string | UTF-8 | empty |
8 bits | must-understand | uimsbf | 0 |
32 bits | header-length | simsbf | variable |
header-length*8 bits | AMF0 or AMF3 | binary | free form |
Length | Name | Type | Default |
---|---|---|---|
16 bits | target-uri-length | uimsbf | variable |
target-uri-length*8 bits | target-uri-string | UTF-8 | variable |
16 bits | response-uri-length | uimsbf | 2 |
response-uri-length*8 bits | response-uri-string | UTF-8 | "/1" |
32 bits | message-length | simsbf | variable |
message-length*8 bits | AMF0 or AMF3 | binary | free form |
If either the header-length or message-length are unknown then they are set to -1 or 0xFFFFFFFF
uimsbf: unsigned integer, most significant bit first
simsbf: signed integer, most significant bit first
AMF0
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 are as below (for AMF0):
- Number - 0x00 (Encoded as IEEE 64-bit double-precision floating point number)
- Boolean - 0x01 (Encoded as a single byte of value 0x00 or 0x01)
- String - 0x02 (16-bit integer string length with UTF-8 string)
- Object - 0x03 (Set of key/value pairs)
- Null - 0x05
- ECMA Array - 0x08 (32-bit entry count)
- Object End - 0x09 (preceded by an empty 16-bit string length)
- Strict Array - 0x0a (32-bit entry count)
- Date - 0x0b (Encoded as IEEE 64-bit double-precision floating point number with 16-bit integer timezone offset)
- Long String - 0x0c (32-bit integer string length with UTF-8 string)
- XML Document - 0x0f (32-bit integer string length with UTF-8 string)
- Typed Object - 0x10 (16-bit integer name length with UTF-8 name, followed by entries)
- Switch to AMF3 - 0x11
AMF objects begin with a (0x03) followed by a set of key-value pairs and end with a (0x09) as value (preceded by 0x00 0x00 as empty key entry). 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 serialized in this way. Both object keys and strings are preceded by two bytes denoting their length in number of bytes. This means that strings are preceded by a total of three bytes which includes the 0x02 type byte. Null types only contain their type-definition (0x05). Numbers are encoded as double-precision floating point and are composed of eight bytes.
As an example, when encoding the object below in actionscript 3 code.
var person:Object = {name:'Mike', age:'30', alias:'Mike'};
var stream:ByteArray = new ByteArray();
stream.objectEncoding = ObjectEncoding.AMF0; // ByteArray defaults to AMF3
stream.writeObject(person);
The data held in the ByteArray is:
Hex code | ASCII |
---|---|
03 00 04 6e 61 6d 65 02 00 04 4d 69 6b 65 00 03 61 67 65 00 40 3e 00 00 00 00 00 00 00 05 61 6c 69 61 73 02 00 04 4d 69 6b 65 00 00 09 |
. . . n a m e . . . M i k e . . a g e . @ > . . . . . . . . a l i a s . . . M i k e . . . |
Note: the object properties can be sorted in a different order from the one in which they are placed in actionscript. For coloring/markup, refer to the legend below.
The code above will work only for built-in classes like Object
. To serialise and deserialise custom classes, the user needs to declare them using the registerClassAlias command or else an error will be thrown by the player.
// for a hypothetical class Person
registerClassAlias("personTypeAlias", Person);
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 01 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 s u c c e e d e d . . . d a t a . . . . . . . v e r s i o n . . . 3 , 5 , 5 , 2 0 0 4 . . . . . c l i e n t i d . A . . x . . . . . . o b j e c t E n c o d i n g . @ . . . . . . . . . . |
legend: object start/end object keys object values ecma_array
The AMF message starts with a 0x03
which denotes an RTMP packet with Header Type of 0, so 12 bytes are expected 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.Success",
description: "Connection succeeded",
data: (array) {
version: "3,5,5,2004" },
clientId: 1584259571.0,
objectEncoding: 3.0 }
Here one 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.
AMF3
The latest version of the protocol specifies significant changes that allow for a more compressed format. The data markers are as follows:
- Undefined - 0x00
- Null - 0x01
- Boolean False - 0x02
- Boolean True - 0x03
- Integer - 0x04 (expandable 8+ bit integer)
- Double - 0x05 (Encoded as IEEE 64-bit double-precision floating point number)
- String - 0x06 (expandable 8+ bit integer string length with a UTF-8 string)
- XML - 0x07 (expandable 8+ bit integer string length and/or flags with a UTF-8 string)
- Date - 0x08 (expandable 8+ bit integer flags with an IEEE 64-bit double-precision floating point UTC offset time)
- Array - 0x09 (expandable 8+ bit integer entry count and/or flags with optional expandable 8+ bit integer name lengths with a UTF-8 names)
- Object - 0x0A (expandable 8+ bit integer entry count and/or flags with optional expandable 8+ bit integer name lengths with a UTF-8 names)
- XML End - 0x0B (expandable 8+ bit integer flags)
- ByteArray - 0x0C (expandable 8+ bit integer flags with optional 8 bit byte length)
The first 4 types are not followed by any data (Booleans have two types in AMF3).
Additional markers used by Flash Player 10 (the format is still referred to as AMF3) are as follows:
- VectorInt - 0x0D
- VectorUInt - 0x0E
- VectorDouble - 0x0F
- VectorObject - 0x10
- Dictionary - 0x11
AMF3 aims for more compression and one of the ways it achieves this is by avoiding string duplication by saving them into an array against which all new string are checked. The byte following the string marker is no longer denoting pure length but it is a complex byte where the least significant bit indicated whether the string is 'inline' (1) i.e. not in the array or 'reference' (0) in which case the index of the array is saved. The table includes keys as well as values.
In older versions of Flash player there existed one number type called 'Number' which was a 64-bit double precision encoding. In the latest releases there is an int and a uint which are included in AMF3 as separate types. Number types are identical to AMF0 encoding while Integers have variable length from 1 to 4 bytes where the most significant bit of bytes 1-3 indicates that they are followed by another byte.
Support for AMF
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:
- ColdFusion -[3]
- Haxe - Haxe Remoting hxformat
- Java - Adobe BlazeDS, Adobe LiveCycle Data Services (formerly known as Flex Data Services), Exadel Flamingo, RED 5, Cinnamon, OpenAMF, Pimento, Granite, WebORB for Java
- .NET - WebORB for .NET, FluorineFx (LGPL), DotAmf (MS-PL), AMF.NET (development stopped)
- PHP - AmfPHP, SabreAMF, WebORB for PHP, Zend_Amf, php-amf3 extension, Baguette AMF(php extension)
- Python - amfast
- Perl - AMF::Perl, Storable::AMF, AMF::Connection
- Curl - Curl Data Services
- Ruby - RubyAMF, WebORB for Rails, Rocket AMF
- Erlang - Erlang-AMF
- ActionScript - Flash Player ByteArray (in-built), CourseVector Library
- JavaScript - JSAMF CourseVector Library CourseVector .minerva
- Lua - lua-amf3
- ABAP - ABAP AMF (early stage)
- Delphi - kbmMW (extensive AMF0/AMF3 support)
- iOS - CocoaAMF
- Powershell - Powershell AMF
Frameworks:
- Ruby on Rails - RubyAMF
- Zend Framework - Zend_AMF
- OSGi Framework - AMF3 for OSGi
- Django - Django AMF
- CakePHP - CakeAMFPHP
- Grails (framework) - BlazeDS
- Trac - TracRpcProtocolsPlugin. Version 1.1.0 (or higher) of XmlRpcPlugin is required.
- Web2py - PyAMF