[rabbitmq-discuss] Passing null for 'arguments' to queueBind()

[Matthias Radestock]

Michi,

michi.oshima wrote:
> I'm currently exploring 'headers' exchange type.  I'd publish a message with
> argument table set to 'A' for example, with the intent that consumer with
> the matching argument 'A' would receive the message.  And those consumers
> who do not specify 'A' would not get the message.
> 
> I'm finding that a consumer ends up receiving all messages if I pass null as
> the value for the 'arguments' parameter. 
> 
> 1. Is this intended?  That is, I merely have to specify null for 'arguments'
> to receive all messages.

Yes, that is the specified behaviour.

> 2. Is there any way to prevent a client from subscribing to all messages?

Not directly, but see below.

> What I'm trying to achieve is some degree of message privacy.  Consumer A
> would put the key 'A' to argument to receive all messages meant for A, and
> Consumer B would put the key 'B' to argument to receive all messages meant
> for B.  Consumer A is prevented from receiving messages meant for Consumer
> B, simply because he is ignorant of the key 'B'.  

So essentially the producer is selecting who is allowed to receive a 
message by listing a set of tokens / shared secrets. Right?

I can think of three ways of doing that with RabbitMQ...

1) The publisher sends the message N times to a direct exchange, each 
time with an individual security token as the routing key. Consumers 
bind to that direct exchange with their token. (You could also just use 
the default exchange, if the consumer's queues are named with their 
token). The downside of this approach is the cost of having to send 
(and for the server to process) the same message multiple times.

2) Write a custom exchange type plug-in. This could work exactly like a 
headers exchange but not permit empty bindings. Or it could work more 
like a direct exchange, with the producer perhaps listing the tokens in 
the message's routing key, comma-separated.

3) Write a proxy that prevents empty bindings.


Regards,

Matthias.