Thank you and enjoy Adobe Flash Player. Here is another product that might interest you. Step: 3 of 3. The following is a literal POST request header sent from a Flex application hosted. Bin—debugHTTPSendParams.swf x—flash—version: 9,0,115,0.
Real-Time Messaging Protocol (RTMP) was initially a proprietary protocol developed by Macromedia for streaming audio, video and data over the Internet, between a Flash player and a server. Macromedia is now owned by Adobe, which has released an incomplete version of the specification of the protocol for public use.
The RTMP protocol has multiple variations:
- The 'plain' protocol which works on top of and uses TCP port number 1935 by default.
- RTMPS, which is RTMP over a TLS/SSL connection.
- RTMPE, which is RTMP encrypted using Adobe's own security mechanism. While the details of the implementation are proprietary, the mechanism uses industry standard cryptographic primitives.[1]
- RTMPT, which is encapsulated within HTTP requests to traverse firewalls. RTMPT is frequently found utilizing cleartext requests on TCPports 80 and 443 to bypass most corporate traffic filtering. The encapsulated session may carry plain RTMP, RTMPS, or RTMPE packets within.
- RTMFP, which is RTMP over UDP instead of TCP, replacing RTMP Chunk Stream. The Secure Real-Time Media Flow Protocol suite has been developed by Adobe Systems and enables end‐users to connect and communicate directly with each other (P2P).
While the primary motivation for RTMP was to be a protocol for playing Flash video, it is also used in some other applications, such as the Adobe LiveCycle Data Services ES.
- 1Basic operation
- 4Packet structure
- 5The protocol
- 7Software implementations
Basic operation[edit]
RTMP is a TCP-based protocol which maintains persistent connections and allows low-latency communication. To deliver streams smoothly and transmit as much information as possible, it splits streams into fragments, and their size is negotiated dynamically between the client and server. Sometimes, it is kept unchanged; the default fragment sizes are 64 bytes for audio data, and 128 bytes for video data and most other data types. Fragments from different streams may then be interleaved, and multiplexed over a single connection. With longer data chunks, the protocol thus carries only a one-byte header per fragment, so incurring very little overhead. However, in practice, individual fragments are not typically interleaved. Instead, the interleaving and multiplexing is done at the packet level, with RTMP packets across several different active channels being interleaved in such a way as to ensure that each channel meets its bandwidth, latency, and other quality-of-service requirements. Packets interleaved in this fashion are treated as indivisible, and are not interleaved on the fragment level.
The RTMP defines several virtual channels on which packets may be sent and received, and which operate independently of each other. For example, there is a channel for handling RPC requests and responses, a channel for video stream data, a channel for audio stream data, a channel for out-of-band control messages (fragment size negotiation, etc.), and so on. During a typical RTMP session, several channels may be active simultaneously at any given time. When RTMP data is encoded, a packet header is generated. The packet header specifies, amongst other matters, the ID of the channel on which it is to be sent, a timestamp of when it was generated (if necessary), and the size of the packet's payload. This header is then followed by the actual payload content of the packet, which is fragmented according to the currently agreed-upon fragment size before it is sent over the connection. The packet header itself is never fragmented, and its size does not count towards the data in the packet's first fragment. In other words, only the actual packet payload (the media data) is subject to fragmentation.
At a higher level, the RTMP encapsulates MP3 or AAC audio and FLV1 video multimedia streams, and can make remote procedure calls (RPCs) using the Action Message Format. Any RPC services required are made asynchronously, using a single client/server request/response model, such that real-time communication is not required.[clarification needed][2][3]
Encryption[edit]
RTMP sessions may be encrypted using either of two methods:
- Using industry standard TLS/SSL mechanisms. The underlying RTMP session is simply wrapped inside a normal TLS/SSL session.
- Using RTMPE, which wraps the RTMP session in a lighter-weight encryption layer.
HTTP tunneling[edit]
In RTMP Tunneled (RTMPT), RTMP data is encapsulated and exchanged via HTTP, and messages from the client (the media player, in this case) are addressed to port 80 (the default for HTTP) on the server.
While the messages in RTMPT are larger than the equivalent non-tunneled RTMP messages due to HTTP headers, RTMPT may facilitate the use of RTMP in scenarios where the use of non-tunneled RTMP would otherwise not be possible, such as when the client is behind a firewall that blocks non-HTTP and non-HTTPS outbound traffic.
The protocol works by sending commands through the POST URL, and AMF messages through the POST body. An example is
for a connection to be opened.
Specification document and patent license[edit]
Adobe has released a specification for version 1.0 of the protocol dated December 21, 2012.[4] The web landing page leading to that specification notes that 'To benefit customers who want to protect their content, the open RTMP specification does not include Adobe's unique secure RTMP measures'.[5]
A document accompanying the Adobe specification grants 'non-exclusive, royalty-free, nontransferable, non-sublicensable, personal, worldwide' patent license to all implementations of the protocol, with two restrictions: one forbids use for intercepting streaming data ('any technology that intercepts streaming video, audio and/or data content for storage in any device or medium'), and another prohibits circumvention of 'technological measures for the protection of audio, video and/or data content, including any of Adobe’s secure RTMP measures'.[6]
Patents and related litigation[edit]
Stefan Richter, author of some books on Flash, noted in 2008 that while Adobe is vague as to which patents apply to RTMP, U.S. Patent 7,246,356 appears to be one of them.[2]
In 2011, Adobe did sue Wowza Media Systems claiming among other things, infringement of their RTMP patents.[7][8][9] In 2015, Adobe and Wowza announced that the lawsuits have been settled and dismissed with prejudice.[10]
Packet structure[edit]
RTMP Packet Diagram
Packets are sent over a TCP connection which is established first between client and server. They contain a header and a body which, in the case of connection and control commands, is encoded using the Action Message Format (AMF). The header is split into the Basic Header (shown as detached from the rest, in the diagram) and Chunk Message Header. The Basic Header is the only constant part of the packet and is usually composed of a single composite byte, where the 2 most significant bits are the Chunk Type (fmt in the specification) and the rest form the Stream ID. Depending on the value of the former, some fields of the Message Header can be omitted and their value derived from previous packets while depending on the value of the latter, the Basic Header can be extended with 1 or 2 extra bytes (as in the case of the diagramme that has 3 bytes in total (c)). If the value of the remaining 6 bits of the Basic Header (BH) (least significant) is 0 then the BH is 2 bytes and represents from Stream ID 64 to 319 (64+255); if the value is 1, then the BH is 3 bytes (with last 2 bytes encoded as 16bit Little Endian) and represents from Stream ID 64 to 65599 (64+65535); if the value is 2, then BH is 1 byte and is reserved for low-level protocol control messages and commands. The Chunk Message Header contains meta-data information such as the message size (measured in bytes), the Timestamp Delta and Message Type. This last value is a single byte and defines whether the packet is an audio, video, command or 'low level' RTMP packet such as an RTMP Ping.
An example is shown below as captured when a flash client executes the following code:
this will generate the following Chunk:
Hex Code | ASCII |
---|---|
03 00 0B 68 00 00 19 14 00 00 00 00 0200 0C63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 00 00 00 05 | ␃ ␀ @ I ␀ ␀ ␙ ␔ ␀ ␀ ␀ ␀ ␂␀ ␌c r e a t e S t r e a m ␀ @ ␀ ␀ ␀ ␀ ␀ ␀ ␀ ␅ |
The packet starts with a Basic Header of a single byte (0x03) where the 2 most significant bits (b00000011) define a chunk header type of 0 while the rest (b00000011) define a Chunk Stream ID of 3. The 4 possible values of the header type and their significance are:
- b00 = 12 byte header (full header).
- b01 = 8 bytes - like type b00. not including message ID (4 last bytes).
- b10 = 4 bytes - Basic Header and timestamp (3 bytes) are included.
- b11 = 1 byte - only the Basic Header is included.
The last type (b11) is always used in the case of aggregate messages where, in the example above, the second message will start with an id of 0xC3 (b11000011) and would mean that all Message Header fields should be derived from the message with a stream Id of 3 (which would be the message right above it). The 6 least significant bits that form the Stream ID can take values between 3 and 63. Some values have special meaning like 1 that stands for an extended ID format, in which case there will be 2 bytes following that. A value of 2 is for low level messages such as Ping and Set Client Bandwidth.
The next bytes of the RTMP Header (including the values in the example packet above) are decoded as follows:
- byte #1 (0x03) = Chunk Header Type.
- byte #2-4 (0x000b68) = Timestamp delta.
- byte #5-7 (0x000019) = Packet Length - in this case it is 0x000019 = 25 bytes.
- byte #8 (0x14) = Message Type ID - 0x14 (20) defines an AMF0 encoded command message.
- byte #9-12 (0x00000000) = Message Stream ID. This (strangely) is in little-endian order
The Message Type ID byte defines whether the packet contains audio/video data, a remote object or a command. Some possible values for are:
- 0x01 = Set Packet Size Message.
- 0x02 = Abort.
- 0x03 = Acknowledge.
- 0x04 = Control Message.
- 0x05 = Server Bandwidth
- 0x06 = Client Bandwidth.
- 0x07 = Virtual Control.
- 0x08 = Audio Packet.
- 0x09 = Video Packet.
- 0x0F = Data Extended.
- 0x10 = Container Extended.
- 0x11 = Command Extended (An AMF3 type command).
- 0x12 = Data (Invoke (onMetaData info is sent as such)).
- 0x13 = Container.
- 0x14 = Command (An AMF0 type command).
- 0x15 = UDP
- 0x16 = Aggregate
- 0x17 = Present
Following the header, 0x02 denotes a string of size 0x000C and values 0x63 0x72 ... 0x6D ('createStream' command). Following that we have a 0x00 (number) which is the transaction id of value 2.0. The last byte is 0x05 (null) which means there are no arguments.
Invoke Message Structure (0x14, 0x11)[edit]
Some of the message types shown above, such as Ping and Set Client/Server Bandwidth, are considered low level RTMP protocol messages which do not use the AMF encoding format. Command messages on the other hand, whether AMF0 (Message Type of 0x14) or AMF3 (0x11), use the format and have the general form shown below:
The transaction id is used for commands that can have a reply. The value can be either a string like in the example above or one or more objects, each composed of a set of key/value pairs where the keys are always encoded as strings while the values can be any AMF data type, including complex types like arrays.
Control Message Structure (0x04)[edit]
Control messages are not AMF encoded. They start with a stream Id of 0x02 which implies a full (type 0) header and have a message type of 0x04. The header is followed by 6 bytes which are interpreted as such:
- #0-1 - Control Type.
- #2-3 - Second Parameter (this has meaning in specific Control Types)
- #4-5 - Third Parameter (same)
The first two bytes of the message body define the Ping Type which can apparently[11] take 6 possible values.
- Type 0 - Clear Stream: Sent when the connection is established and carries no further data
- Type 1 - Clear the Buffer.
- Type 2 - Stream Dry.
- Type 3 - The client's buffer time. The third parameter holds the value in millisecond.
- Type 4 - Reset a stream.
- Type 6 - Ping the client from server. The second parameter is the current time.
- Type 7 - Pong reply from client. The second parameter is the time when the client receives the Ping.
- Type 8 - UDP Request.
- Type 9 - UDP Response.
- Type 10 - Bandwidth Limit.
- Type 11 - Bandwidth.
- Type 12 - Throttle Bandwidth.
- Type 13 - Stream Created.
- Type 14 - Stream Deleted.
- Type 15 - Set Read Access.
- Type 16 - Set Write Access.
- Type 17 - Stream Meta Request.
- Type 18 - Stream Meta Response.
- Type 19 - Get Segment Boundary.
- Type 20 - Set Segment Boundary.
- Type 21 - On Disconnect.
- Type 22 - Set Critical Link.
- Type 23 - Disconnect.
- Type 24 - Hash Update.
- Type 25 - Hash Timeout.
- Type 26 - Hash Request.
- Type 27 - Hash Response.
- Type 28 - Check Bandwidth.
- Type 29 - Set Audio Sample Access.
- Type 30 - Set Video Sample Access.
- Type 31 - Throttle Begin.
- Type 32 - Throttle End.
- Type 33 - DRM Notify.
- Type 34 - RTMFP Sync.
- Type 35 - Query IHello.
- Type 36 - Forward IHello.
- Type 37 - Redirect IHello.
- Type 38 - Notify EOF.
- Type 39 - Proxy Continue.
- Type 40 - Proxy Remove Upstream.
- Type 41 - RTMFP Set Keepalives.
- Type 46 - Segment Not Found.
Pong is the name for a reply to a Ping with the values used as seen above.
ServerBw/ClientBw Message Structure (0x05, 0x06)[edit]
This relates to messages that have to do with the client up-stream and server down-stream bit-rate. The body is composed of 4 bytes showing the bandwidth value with a possible extension of one byte which sets the Limit Type. This can have one of 3 possible values which can be: hard, soft or dynamic (either soft or hard).
Set Chunk Size (0x01)[edit]
The value received in the 4 bytes of the body. A default value of 128 bytes exists and the message is sent only when a change is wanted
The protocol[edit]
RTMP Handshake Diagram
Handshake[edit]
After establishing a TCP connection, an RTMP connection is established first performing a handshake through the exchange of 3 packets from each side (also referred as Chunks in the official documentation). These are referred in the official spec as C0-2 for the client sent packets and S0-2 for the server side respectively and are not to be confused with RTMP packets that can be exchanged only after the handshake is complete. These packets have a structure of their own and C1 contains a field setting the 'epoch' timestamp but since this can be set to zero, as is done in third party implementations, the packet can be simplified. The client initialises the connection by sending the C0 packet with a constant value of 0x03 representing the current protocol version. It follows straight with C1 without waiting for S0 to be received first which contains 1536 bytes, with the first 4 representing the epoch timestamp, the second 4 all being 0, and the rest being random (and which can be set to 0 in third party implementations). C2 and S2 are an echo of S1 and C1 respectively, except with the second 4 bytes being the time the respective message was received (instead of 0). After C2 and S2 are received the handshake is considered complete.
Connect[edit]
At this point, the client and server can negotiate a connection by exchanging AMF encoded messages. These include key value pairs which relate to variables that are needed for a connection to be established. An example message from the client is:
The Flash Media Server and other implementations uses the concept of an 'app' to conceptually define a container for audio/video and other content, implemented as a folder on the server root which contains the media files to be streamed. The first variable contains the name of this app as 'sample' which is the name provided by the Wowza Server for their testing. The
flashVer
string is the same as returned by the Action-script getversion()
function. The audioCodec
and videoCodec
are encoded as doubles and their meaning can be found in the original spec. The same is true for the videoFunction
variable which in this case is the self-explanatory SUPPORT_VID_CLIENT_SEEK constant. Of special interest is the objectEncoding
which will define whether the rest of the communication will make use of the extended AMF3 format or not. As version 3 is the current default, the flash client has to be told explicitly in Action-script code to use AMF0 if that is requested. The server then replies with a ServerBW, a ClientBW and a SetPacketSize message sequence, finally followed by an Invoke, with an example message.Some of the values above are serialised into properties of a generic Action-script Object which is then passed to the NetConnection event listener. The
clientId
will establish a number for the session to be started by the connection. Object encoding must match the value previously set.Play video[edit]
To start a video stream, the client sends a 'createStream' invocation followed by a ping message, followed by a 'play' invocation with the file name as argument. The server will then reply with a series of 'onStatus' commands followed by the video data as encapsulated within RTMP messages.
After a connection is established, media is sent by encapsulating the content of FLV tags into RTMP messages of type 8 and 9 for audio and video respectively.
HTTP tunneling (RTMPT)[edit]
This refers to the HTTP tunneled version of the protocol. It communicates over port 80 and passes the AMF data inside HTTP POST request and responses. The sequence for connection is as follows:
The first request has an
/fcs/ident2
path and the correct reply is a 404 Not Found error. The client then sends an /open/1 request where the server must reply with a 200 ok appending a random number that will be used as the session identifier for the said communication. In this example 1728724019 is returned in the response body.From now on the
/idle/<session id>/<sequence #>
is a polling request where the session id has been generated and returned from the server and the sequence is just a number that increments by one for every request. The appropriate response is a 200 OK with an integer returned in the body signifying the interval time. AMF data is sent through /send/<session id>/<sequence #>
Software implementations[edit]
RTMP is implemented at these three stages:
- Live video encoder
- Live and on-demand media streaming server
- Live and on-demand client
rtmpdump[edit]
The open-source RTMP client command-line tool rtmpdump is designed to play back or save to disk the full RTMP stream including the RTMPE protocol Adobe uses for encryption. RTMPdump runs on Linux, Android, Solaris, Mac OS X, and most other Unix-derived operating systems, as well as Microsoft Windows. Originally supporting all versions of 32-bit Windows including Windows 98, from version 2.2 the software will run only on Windows XP and above (although earlier versions remain fully functional).
Packages of the rtmpdump suite of software are available in the major open-source repositories (GNU/Linux distributions). These include the front-end apps 'rtmpdump', 'rtmpsrv' and 'rtmpsuck.'
Development of RTMPdump was restarted in October 2009, outside the United States, at the MPlayer site.[12] The current version features greatly improved functionality, and has been rewritten to take advantage of the benefits of the C programming language. In particular, the main functionality was built into a library (librtmp) which can easily be used by other applications. The RTMPdump developers have also written support for librtmp for MPlayer, FFmpeg, XBMC, cURL, VLC and a number of other open source software projects. Use of librtmp provides these projects with full support of RTMP in all its variants without any additional development effort.
FLVstreamer[edit]
FLVstreamer is a fork of RTMPdump, without the code which Adobe claims violates the DMCA in the USA. This was developed as a response to Adobe's attempt in 2008 to suppress RTMPdump. FLVstreamer is an RTMP client that will save to disk ('download') a stream of audio or video content from any RTMP server, if encryption (RTMPE) is not enabled on the stream.
See also[edit]
- Protected Streaming Info about RTMPS and RTMPE
- Real-Time Media Flow Protocol (RTMFP), based on UDP
- Video on Demand (VoD)
References[edit]
- ^'RTMPE'. Adobe Flash Lite 4 Help. Adobe. Retrieved 29 December 2013.
- ^ ab'TheRealTimeWeb.com: Adobe Patents RTMP'. www.therealtimeweb.com.
- ^'Using RPC services in Flex Data Services 2'. Archived from the original on 3 April 2007. Retrieved 16 April 2007.Cite journal requires
|journal=
(help) - ^H. Parmar, M. Thornburgh (eds.) Adobe’s Real Time Messaging Protocol, Adobe, December 21, 2012
- ^'Real-Time Messaging Protocol (RTMP) specification'. Retrieved 8 May 2014.
- ^RTMP Specification License, Published April 2009
- ^Schumacher-Rasmussen, Eric (27 May 2011). 'Wowza Denies Adobe's Allegations of Patent Infringement'. streamingmedia.com.
- ^Lawler, Ryan (31 May 2011). 'Wowza Fires Back at Adobe in Flash Patent Suit'. gigaom.com.
- ^'ADOBE SYSTEMS INCORPORATE - No. C 11-2243 CW. - 20120907565 - Leagle.com'. leagle.com.
- ^Wowza Media Systems and Adobe Systems Settle Patent Cases http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases
- ^The Red5 Project (2009) Ping. Available from: http://trac.red5.org/wiki/Documentation/Tutorials/Ping. Accessed at: 25 December 2011
- ^'Updates:2009-11-01'. Retrieved 1 November 2009.
External links[edit]
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Real-Time_Messaging_Protocol&oldid=926917370'
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).
- 1Format analysis
Format analysis[edit]
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 in December 2007[2][3] and announced that it will support the developer community to make this protocol available for every major server platform.
AMF self-contained packet[edit]
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[edit]
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.
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.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 0903 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 49 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/endobject keysobject valuesecma_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: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[edit]
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.
![Header Header](http://3.bp.blogspot.com/-Xj-lQAvSbnI/VG3WwQZ-oLI/AAAAAAAAD-U/jbj8eV9MD6I/s1600/2014-11-20_12h42_12.png)
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[edit]
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 -[4]
- Haxe - Haxe Remotinghxformat
- 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 - JSAMFCourseVector LibraryCourseVector .minerva
- Lua - lua-amf3
- ABAP - ABAP AMF (early stage)
- Delphi - kbmMW (extensive AMF0/AMF3 support)
- iOS - CocoaAMF
- Powershell - Powershell AMF
Frameworks:
- Apache Royale communication with AMF and RemoteObject - Apache Royale
- 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
See also[edit]
References[edit]
![What are x headers What are x headers](http://lh3.ggpht.com/_0j4bzarlOBg/TSRLmaz935I/AAAAAAAABp8/Tq2o1KA6Jpk/image_thumb[2].png?imgmax=800)
- ^'Action Message Format -- AMF 3'(PDF). January 2013. Archived from the original(PDF) on 2017-12-31. Retrieved 2017-12-31.
- ^'Action Message Format -- AMF 0'(PDF). 2007. Archived from the original(PDF) on 2017-12-31. Retrieved 2017-12-31.
- ^'Adobe opens up AMF, liberates source for remoting framework used in rich web apps'. Ars Technica. Retrieved 2017-12-31.
- ^Features | Adobe ColdFusion 9 Standard
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Action_Message_Format&oldid=923600568'