[rabbitmq-discuss] py-amqplib and rabbit default

[Simon MacMullen]

On 31/07/10 11:28, Matthew Sackman wrote:
> On Fri, Jul 30, 2010 at 08:01:31PM -0500, tsuraan wrote:
>> I just updated to default (wanting to try out the disk persister that
>> just merged in), and it doesn't look like py-amqplib can handshake
>> with it anymore.  It's protocol header is AMQP\x01\x01\x09\x01 (which
>> seems like a strange header for the 0.8 client, but anyhow...).  In
>> the bug21673 branch, the handshake pattern was
>> AMQP\x01\x01\x<Major>\x<Minor>, but in default, it's now divided into
>> AMQP0091, AMQP1109, and AMQP1180.  Why was this done?  Changing the
>> header string in py-amqplib is easy enough, but it seems weird that a
>> client cannot be compatible with the old rabbit and the new one.
>
> Ahh well the multi-protocol broker stuff landed yesterday so the broker
> can now speak AMQP 0-8 and 0-9-1. I wonder whether we've managed to get
> protocol negotiation wrong. I'm afraid I've not worked on that area of
> the codebase and don't really understand the bizarre complexities of
> protocol negotiation in AMQP at all so this might have to wait until
> Monday... What may be more likely is that the py-amqplib always sent a
> 0-9-1 protocol header which we accepted and told it we were only going
> to speak 0-8 to it. But it may be the 0-9-1 header it was sending was
> actually wrong as far as the 0-9-1 spec says. Certainly I'm aware we've
> found other AMQP brokers that get the protocol header wrong too...

Speaking as someone who did work on this, that's basically it.

In theory each of the four bytes after "AMQP" have meaningful semantics. 
However, each version of the AMQP standard seems to manage to assign 
them *different* semantics, so in practice we just pattern-match.

The standards say[0]:

AMQP1180 = 0-8
AMQP1109 = 0-9
AMQP0091 = 0-9-1

And yes, that's not exactly a regular pattern there, but that's what the 
specs say.

However, we weren't aware that there were clients out there in the wild 
sending even odder handshakes. Unfortunately the 0-8 handshake code that 
was in RabbitMQ up till Friday was quite lax; accepting either 0-8, or 
any version that claimed to be higher than 0-8 by the 0-8 semantics of 
each of the bytes. Hence AMQP1191 was accepted, and treated as 0-8. Now 
we're stricter, and reject it.

I'm not sure what the best approach is. Our goal was for 0-9-1 support 
to just appear and work, and not inconvenience any existing 0-8 users. 
With that in mind, I suspect we'll end up adding a workaround for 
py-amqplib, treating AMQP1191 as 0-8. But not until Monday :) Of course, 
py-amqplib should be fixed too.

Cheers, Simon

[0] Whenever I write AMQPabcd, please treat the four digits as byte 
values not ASCII characters.