[rabbitmq-discuss] anyone using Twisted?

Sun Aug 24 18:29:32 BST 2008

Matthias Radestock wrote:
> Holger Hoffstätte wrote:
>> As an aside, does anybody know whether the AMQP spec mandates the m:1
>> channel:connection relationship, or is that just what's implemented right
>> now in Rabbit?
> 
> The spec allows for multiple channels per connection, and multiple
> connections per client.

I'm afraid your answer is completely correct and yet not what I wanted to
know. ;-)
I'll admit the question was ambiguous.

>> IMHO clients in general could also benefit greatly from
>> bonding multiple connections together; the Java client might be able to
>> use NIO for that. This could cut down connection contention with many
>> channels and allow for better network utilization, though it would
>> need to
>> be handled by the broker as well. Just curious.
> 
> Are you referring to ethernet bonding? Please elaborate.

More like "socket bonding" if that makes sense - the question (and
half-baked idea) was whether a logical connection could be implemented in
terms of multiple sockets (when using TCP), without the client app doing
this manually/explicitly. Allowing multiple sockets could prevent channel
starvation and therefore also better QoS schemes, but on second thought it
is not clear whether just delegating to the OS is such a good idea after all.

A typical scenario would be a couple of channels that send/receive mostly
small messages at varying rates but with low latency requirement, yet the
one oddball sends huge messages but doesn't care about the transfer speed.
Without some kind of fairness on the framing level (e.g. by dividing up
the one shared socket among all channels with some kind of quota, channel
priority or deadline), the one big sender could starve the other small
messages.

I'm not sure if this is important at this point, or even whether doing
this kind of QoS on the frame level (ala a packet scheduler) or on a
per-socket level would be better. I dind't find any useful QoS information
in the spec except for the note on the Channel class and the per-message
credit-based "flow control" concept, but to me that seems of little use
for starvation control on the transport level. From what I can tell that
(and session ordering) is what the frame "Tracks" in 0.10 are about, I
didn't see that in 0.8/0.9.

Enough elaborated, I guess. :)

regards
Holger