How does AMQP overcome the difficulties of using TCP directly?

Question

How does AMQP overcome the difficulties of using TCP directly when sending messages? Or more specifically in a pub/sub scenario?

Answer 1

In AMQP there is a broker, that broker receives the messages and then does the hard part about routing them to exchanges and queues. You can also setup durable queues which save the messages for clients even when they are disconnected.

You could certainly do all this yourself, but it's a tremendous amount of work to do correctly. RabbitMQ in particular has been battle tested in many deployments.

You are still using the TCP protocol underneath AMQP, AMQP provides a higher abstraction.

You would also have to choose a wire protocol to use with all your clients, where AMQP already defines that wired protocol.

Answer 2

It overcomes difficulties by using one and same TCP connection for all of your threads for performance. AMQP is able to do it by using channels. These channels is a virtual connection inside the “real” TCP connection, and it’s over the channel that you issue AMQP commands.

As each thread spins up, it creates a channel on the existing connection and gets its own private communication path to broker without any additional load on your operating system’s TCP stack.

As a result, you can create a channel hundreds or thousands of times a second without your operating system seeing so much as a blip. There’s no limit to how many AMQP channels you can have on one TCP connection. Think of it like a bundle of fiber optic cable.

Source book: RabbitMq in Action