[rabbitmq-discuss] ? about rabbitmq 1.7.1 and 7-byte frame headers

Tue Feb 16 18:13:03 GMT 2010

On 2010-02-16, at 13:38 , Michael Bridgen wrote:

> James,
>
> As a preface, let me note that 0-9-1 is in part a rationalisation  
> of the specification, and in part an encoding of what brokers  
> actually implement.  0-8 had ambiguities and inconsistencies quite  
> aside from the more obvious mistakes (like the grammar for the  
> protocol header), but what the brokers ended up implementing was by  
> and large consistent.
>
> If you're planning to implement an AMQP peer, personally speaking I  
> would go for 0-9-1 and forget about 0-8.

your note, below, refers to rabbitmq's imminent plans. how does this  
reflect the state and intentions of other brokers?

>   Not only has it fewer mistakes, but it is also (or will be soon,  
> see below) a stable point of interoperability.
>
>>> james anderson wrote:
>>>> a recently built rabbitmq server server indicates - even to the  
>>>> level  of the response server properties, that it implements  
>>>> "amqp 8-0", but
>>>> a. if one connects with a 9-1 version token, it does not  
>>>> disconnect.  it proceeds to negotiate the connection.
>>>
>>> That is expected behaviour for a 0-8 broker, at the least by some  
>>> interpretations of the spec - if the client specifies a higher  
>>> version number than supported by the server then negotiation  
>>> proceeds with the server sending the version it supports.
>
> The protocol negotiation is a bit odd.  In the technical spec (PDF)  
> it says what you have said above; in the XML it adds the rule "The  
> server MUST provide a protocol version that is lower than or equal  
> to that requested by the client in the protocol header."

i must admit, page-8/lines-3-5 of amqp-xml-doc0-8.pdf resisted  
comprehension. in the end, however, the second sentence, can be  
interpreted to restrict the meaning of a lower protocol number to  
indicate only how far down the broker can go, as that sentence  
precludes the broker from sending the start command if it can not  
support the requested - higher - version.
anyway, i take from your remarks, that other implementors reached  
different conclusions.

>
> Hence you can have a negotiation which goes:
> Client: Hi, I would like to use protocol 0-9-1
> Server: Sure!  I support that.  OK, let's use version 0-8
> Client: WTF?
>
> So yeah, a bit nuts.
>
>> that is to say, page-52/line-38 and the diagrams at page-52/line32  
>> and page-53/line-11 of amqp8-0.pdf are no more a misrepresentation  
>> of "accordingly" for a purported r8.0 broker than the indication  
>> in `amqp-xml-doc0-8.pdf` that it applies to "AMQ Protocol  
>> (major=10, minor=3)"?
>>>
>>> NB: the correct protocol header for 0-9-1 is in fact AMQP  
>>> 0-0-9-1, whereas for 0-8 it is AMQP 1-1-8-0, and for 0-9 it is  
>>> AMQP 1-1-0-9. Yes, that is crazy.
>> cool.
>> hmmm... what does the ampq 1-1-9-1 protocol header from the r8.0  
>> and the r9.1 specs actually mean?
>> is that what you intended, above, with "AMQP 0-0-9-1"?
>
> In 0-9-1 the protocol header is 'AMQP0091'.  The last four digits  
> are the constant 0 (protocol-id, whatever that is), then the major,  
> minor and revision numbers.  The 0-8 and 0-9 specs gave these  
> digits a different meaning (and the first two were effectively  
> constants).
>
> I just tried connecting to a RabbitMQ from default branch and  
> giving a 0-9-1 header, and it wrote AMQP1180 and closed the  
> connection, as specified.  From which branch did you build?

from the 1.7.1 release.
i had misunderstood the version-to-header mapping and had, in fact,  
sent it a 0.9r0 protocol header, not a 0.9r1 header. to wit:

? (defparameter *c* (make-instance 'amqp:connection :uri "amqp:// 
guest:guest at localhost/"))
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: open-connection:  
requesting version: #(65 77 81 80 1 1 0 9)/:AMQP-1-1-0-9-1.
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: open-connection:  
byte-zero: 1, updated class to AMQP-1-1-0-9-1:CONNECTION.
[20100216T123124Z00] DEBUG #<CHANNEL [amqp://localhost/].0  
#xF757B2E>: process-command: #<CONNECTION #xF753016>  
#<CONNECTION.START #xF759DEE> . (:VERSION-MAJOR 8 :VERSION-MINOR  
0 :SERVER-PROPERTIES (:|product| "RabbitMQ" :|version| "1.7.1" :| 
platform| "Erlang/OTP" :|copyright| "Copyright (C) 2007-2009 LShift  
Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies  
Ltd." :|information| "Licensed under the MPL.  See http:// 
www.rabbitmq.com/") :MECHANISMS "PLAIN AMQPLAIN" :LOCALES "en_US")
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: send-method:  
START-OK . (:CLIENT-PROPERTIES NIL :MECHANISM "PLAIN" :RESPONSE  
"guestguest" :LOCALE "en_US")
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: encoding:  
CONNECTION.START-OK . (:CLIENT-PROPERTIES NIL :MECHANISM  
"PLAIN" :RESPONSE "guestguest" :LOCALE "en_US")
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: send-method:  
#<CONNECTION.START-OK #xF75A34E>  #<OUTPUT-FRAME [(+)METHOD|0|c.0|t. 
0].{CONNECTION.START-OK}[36/4088: 0 10 0 11 0 0 0 0 ... 115 116 5 101  
110 95 85 83] #xF75A446>
[20100216T123124Z00] DEBUG #<CHANNEL [amqp://localhost/].0  
#xF757B2E>: process-command: #<CONNECTION #xF753016>  
#<CONNECTION.TUNE #xF75B67E> . (:CHANNEL-MAX 0 :FRAME-MAX  
131072 :HEARTBEAT 0)
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: send-method: TUNE- 
OK . (:CHANNEL-MAX 0 :FRAME-MAX 131072 :HEARTBEAT 0)
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: encoding:  
CONNECTION.TUNE-OK . (:CHANNEL-MAX 0 :FRAME-MAX 131072 :HEARTBEAT 0)
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: send-method:  
#<CONNECTION.TUNE-OK #xF75B886>  #<OUTPUT-FRAME [(+)METHOD|0|c.0|t.0]. 
{CONNECTION.TUNE-OK}[12/4088: 0 10 0 31 0 0 0 2 0 0 0 0] #xF75A446>
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: send-method:  
OPEN . (:VIRTUAL-HOST "/")
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: encoding:  
CONNECTION.OPEN . (:VIRTUAL-HOST "/")
[20100216T123124Z00] DEBUG #<CONNECTION #xF753016>: send-method:  
#<CONNECTION.OPEN #xF75BBEE>  #<OUTPUT-FRAME [(+)METHOD|0|c.0|t.0]. 
{CONNECTION.OPEN}[8/4088: 0 10 0 40 1 47 0 0] #xF75A446>
[20100216T123124Z00] DEBUG #<CHANNEL [amqp://localhost/].0  
#xF757B2E>: process-command: #<CONNECTION #xF753016>  
#<CONNECTION.OPEN-OK #xF75BE5E> . NIL
*C*
? (type-of *c*)
AMQP-1-1-0-9-1:CONNECTION

to which it responded with a Connection.Start with a version 8 in the  
properties.
having now rewired it to follow the suggested version->header mapping  
i observe the expected response to a 'standard' 0.9r1 header:

? (defparameter *c* (make-instance 'amqp:connection :uri "amqp:// 
guest:guest at localhost/"))
[20100216T180229Z00] DEBUG #<CONNECTION #x102F73F6>: open-connection:  
requesting version: #(65 77 81 80 0 0 9 1)/:AMQP-1-1-0-9-1.
[20100216T180229Z00] DEBUG #<CONNECTION #x102F73F6>: open-connection:  
parsed version: #(65 77 81 80 1 1 8 0) / :AMQP-1-1-0-8-0.
[20100216T180229Z00] DEBUG #<CONNECTION #x102F73F6>: open-connection:  
updated class to AMQP-1-1-0-8-0:CONNECTION.
[20100216T180229Z00] DEBUG #<CONNECTION #x102F73F6>: open-connection:  
requesting version: #(65 77 81 80 1 1 8 0)/:AMQP-1-1-0-8-0.
[20100216T180229Z00] DEBUG #<CONNECTION #x102F73F6>: open-connection:  
byte-zero: 1, connection class AMQP-1-1-0-8-0:CONNECTION.
 > Error: Frame length exceeds buffer size: 73728, #<VECTOR 4087 type  
(UNSIGNED-BYTE 8), simple>
 > While executing: CCL::%ASSERTION-FAILURE
 > Type Command-/ to continue, Command-. to abort.
 > If continued: test the assertion again.
See the Restarts… menu item for further choices.
1 >

the frame size error being the same as that which had led yesterday  
to the realization that it was using 7-byte headers.

>
>>>> b. it does not use the 8-byte frame headers which appear in  
>>>> every  instance of the amqp0-8 specification the net had  
>>>> yielded, but rather  7-byte headers that are specified for 9-1.
> >>
>>> All implementations of 0-8 actually use a 7-byte header. Hence  
>>> the correction in 0-9-1.
>> do these two sentences boggle any other minds?
>> a naive reader of the r8.0 specification might misconstrue it to  
>> require, that such a correction would apply to a broker which  
>> purports to follow the r9.1 spec, but not to broker which purports  
>> to follow the r8.0 spec. in this light, i have rescanned the r8.0  
>> spec, but did not observe any formulations of the order "or any  
>> later protocol version." ok. anyway, i gather that page-35/line-26  
>> and page-53/line-29 of amqp8-0.pdf are history. is there anything  
>> else of which a naive implementor should be aware?
>
> Many things, I should think, sadly.  The things corrected, or  
> cleared up, in 0-9-1 give some indication.

what does this imply for the way the broker handles realms and tickets?

is is that
1. every 0.8r0 and 0.9r* broker follows 0.9r1 framing specifications.
2. the respective 0.8 and 0.9 brokers each otherwise implement the  
classes/methods/arguments/rules in the respective .xml version of the  
specification.

?

>
> > [...]
>
>> ? are there actually any r9.0 brokers in the wild?
>
> Qpid's Java broker implements 0-9 and 0-9-1, inter alia.  RabbitMQ  
> has a branch implementing 0-9-1 (amqp_0_9_1 in the broker and most  
> of the client repos), which should make its way into releases once  
> work on the new persister is done.
>
>> on a meta level: how does this community achieve interoperability,  
>> other by knowing each other's code?
>
> Also by using each other's code; e.g., we use Qpid's (Python) test  
> suites, in part, and they have been using our 0-9-1 (Java) test suite.
>
>
> mikeb.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100216/238581fb/attachment.htm 