Adobe's documentation for the AMF format does not seem to actually specify the structure of an entire AMF message. It only specifies the format of individual data types. I've read the damn thing five times and either I'm just totally missing what an actual AMF message should contain, or it's not there. Does anyone know of any documentation of the actual whole-message structure?

+3  A: 

The specification might be described as "terse."

The AMF encoding uses bytes which are called "type-markers." The type-marker for an integer is the value 4. The integer data immediately follows this tag, and is 1-4 bytes long. The length varies because the integer type is "compressed" so that values 0-127 require only 1 byte, while larger values require more bytes. This integer format is called "U29" by the specification.

As an example, if we were to simply pass the integer "5", a valid AMF packet would be these two bytes:
04 05

In applications found on the web, the AMF data is sometimes preceded by a length encoded as an unsigned long in network byte order. If you were observing such an application, you might see:
00 00 00 02 04 05, where the 00 00 00 02 indicates that the following AMF data is 2 bytes long.

Now, suppose we sent an object after it had the following constructor:

   this.ui = "button_press";
   this.param = 5;

Then we might see the following in the AMF data:

0A - the object tag
2B - u29o-val: 2 sealed members, object with traits and data, possibly dynamic members
01 - empty string -- anonymous object
05 - string-by-value, string length: 2
75 69 - 'ui'
0B - string-by-value, string length: 5
70 61 72 61 6D - 'param'
19 - string-by-value, string length: 12
62 75 74 74 6F 6E 5F 70 72 65 73 73 - 'button_press'
04 - integer
05 - value of integer: 5
01 - empty name, terminates empty list of dynamic members this object

Since that packet will take 28 bytes, it may be prefixed by: 00 00 00 1C when encountered in the wild.

Another possibility to consider is that AMF communications may be compressed, typically using the "deflate" compression available in zlib.

I hope this helps you sort out the specification, but if you have questions, I would try to answer them.

Heath Hunnicutt
Thanks, very helpful. I was actually hoping that somewhere there's a BNF description of an entire valid AMF message, including headers and whatnot; I went throught he code for AMFPHP just to see what it does when it's decoding, and there was a lot of stuff in there that wasn't even hinted at in the actual spec, let alone described in detail.
+1  A: 

If you are looking for remoting message structure it is appended to the end of the AMF0 spec - Section 4