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

Tue Feb 16 18:24:38 GMT 2010

James

Just to address your first question, our aim is convergence to 0-91
and this is mutual in that Qpid 0.6 (Java) and OpenAMQ pass enough
0-91 tests to be able to call themselves 0-91 brokers.  Each one has
some unimplemented parts eg OpenAMQ don't do persistence IIRC.  I have
cc'd the relevant folks.  I'm sorry it's taken us so long - there are
some reasons for this but nothing surprising.  Do also note that Qpid
C++ is on 0-10 and will stay there.  In the future there will be an
AMQP 1-0 which will enable even greater convergence, and a wider set
of implementations.

I hope someone else will pick up on your other questions.

Let me know if this helps.

alexis

On Tue, Feb 16, 2010 at 6:13 PM, james anderson <james.anderson at setf.de> wrote:
>
> 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@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@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.
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>