[rabbitmq-discuss] py-amqplib being reworked

[Ben Hood]

Michael,

On Tue, Dec 2, 2008 at 7:43 AM, Michael Arnoldus <chime at mu.dk> wrote:
>> ATM Rabbit does not support rejections, this is currently on the todo
>> list.
>
> My bad - I meant basic.return.
>
>> When using the current implementation (i.e. using a thread per channel
>> and multiplexing across a single socket connection), this does seem
>> the way to go.
>>
>> However, there is some discussion as to whether one should multiplex
>> within a single socket connection or whether one should use multiple
>> sockets to send independent streams of data.
>
> Well that makes sense - still I can't see how you can accept basic.return
> while consuming a queue without using threads - or have I missed something?
> Also, when waiting on a single thread how can I stop basic.consume?

Good question, I don't think that it's very expressive without using
some kind of thread model - although obviously from a kernel
perspective, everything is just a state machine :-)

Having said that, I think you *may* have taken what I said out of
perspective - just because you get rid of channels does not mean that
that you have to get rid of client side threads. The main motivation
behind command multiplexing within a single TCP connection *seems* to
be to allow multiple clients threads to use a single connection.
However, it is conceivable that each client side thread could have
it's own transport layer connection (or not-connection in the case of
UDP). So a client could thread as much as it likes, and the server
could remain oblivious of this.

The reason why command multiplexing has been questioned is because it
*apparently* re-invents flow control mechanisms that are already
available in TCP and SCTP.

I think that the question about threading is more of a client design
issue than a general protocol discussion.

HTH,

Ben