[rabbitmq-discuss] anyone using Twisted?

Sun Aug 24 19:29:22 BST 2008

Holger,

Holger Hoffstätte wrote:
> Matthias Radestock wrote:
>> 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.

What's wrong with having multiple logical (and thus TCP) connections? 
Does your application depend on having a single logical connection? I'd 
find that surprising given that the connection doesn't feature as a 
logical entity in most AMQP operations; most things happen at the 
granularity of channels.

> 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.

The broker does a reasonably good job of treating channels fairly. Large 
messages will be split across multiple frames, allowing smaller messages 
from other channels to be interleaved.

As you say, sending the messages across different TCP connections just 
delegates the problem to the OS. That's probably a good thing, but 
whether it actually gives you any better fairness only testing will reveal.

Matthias.