[rabbitmq-discuss] anyone using Twisted?
matthias at lshift.net
Sun Aug 24 19:29:22 BST 2008
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
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.
More information about the rabbitmq-discuss