Does ServiceBusReceiver use a pull or a push communication model when talking to Azure Service Bus?

Just out of curiosity: What exactly happens behind the scenes when we call and await ServiceBusReceiver.ReceiveMessageAsync() or ServiceBusReceiver.ReceiveMessageAsync(TimeSpan.FromMinutes(10))?

Does

a.) the ServiceBusReceiver (long-)poll Azure Service Bus or does

b.) Azure Service Bus send somehow push notifications to the ServiceBusReceiver?

I tried to look into the source code, but didn't get far, because some class InnerReceiver is used that I couldn't find in the code base.

FINAL EDIT

On the ServiceBus Sdk level it is a pull communication model, just to better handle confirmation of incoming messages.

But behind the scenes azure service bus sdk uses Advanced Message Queuing Protocol 1.0 which doesn't long poll, it uses AmqpLinks on the same AmqpConnection to send data from a sender to a receiver, and the receiver saves the incoming messages to an in-memory buffer on receiving them.

You can read more about it here
or See this video series from Microsoft about the AMQP 1.0 protocol.

So it seems that the answer to "What exactly happens behind the scenes" is neither A nor B, Messages are being pushed to the ReceivingAmqpLink (to an in-memory buffer), which then the ServiceBusReceiver pulls from.

I hope this answer will close this discussion, and everyone will be happy

The source codes:

Azure.Messaging.ServiceBus

Azure.Amqp

ServiceBusReceiver wraps the AmqpReceiver

wrapping the ReceiveMessagesAsync of the AmqpReceiver

Creating the ReceivingAmqpLink in the constructor of the AmqpReceiver

Opening the ReceivingAmqpLink on the same connection if possible

Caching the messages on the ReceivingAmqpLink's buffer

Pulling the messages from the buffer into the ReceiveAsyncResult

The public async function that creates the ReceiveAsyncResult

Calling the that "public async function" on AmqpReceiver.ReceiveMessagesAsync

I think @Ethen.S answer is not correct. Moreover neither (a) nor (b) from original question are true:

• Service Bus in its core is pull based system (see https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/messaging#pull-model)
• ServiceBusReceiver.ReceiveMessageAsync seems to be implemented in "async all the way" fashion as far as IO for this individual operation is concerned, meaning async operation is initiated, caller thread is "released" and then at some point async operation is completed upon notification and awaited Tasks are completed, continuations queued, etc... Note that it does not mean that the whole Service Bus <-> Consumer interaction can be considered a "push model" because a Client of the ServiceBusReceiver has to do polling on top of it.
• The only mentioned "push model" integration seems to be possible via Event Grid (see https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-to-event-grid-integration-concept?tabs=event-grid-event-schema)

You might want to take a look at Azure.Messaging.ServiceBus.ServiceBusProcessor (use StartProcessingAsync method as an entry point for investigation) source to better understand the dichotomy there. It exposes an event that you subscribe to and handle the messages "reactively", but it still does a sequence of the ReceiveMessageAsync for you. What might look "push" model from the consumer perspective might still rely on "poll" model behind the scenes.

Please also note that there is a concept of Message Prefetching which can optimise some of the consumption scenarios, but it has its caveats to be considered as well (see https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-prefetch?tabs=dotnet#why-is-prefetch-not-the-default-option). It is still the same polling strategy, but with an additional client-level buffer on top.

UPDATE. I dug deeper into that to capture what happens on wire.

I've used sslsplit in order to make MITM attack to capture TLS-protected AMQP connection decrypted data. Test application setup is simple:

• Receiver is doing ReceiveMessageAsync in a loop
• After some time sender sends a message (two times)

In summary, this is indeed neither "poll" nor "push" as definitions are rather vague. What we can say for sure is that:

• it uses persistent TCP connection
• receival is controlled by the Client side using "Link Credit" (via the "flow" performative)
• when client is idle waiting for messages once in about 30 seconds empty AMQP message is sent
• Service Bus has mechanism to notify the receiver efficiently if there are enough "Link Credit"

I've put test code and test harness here: https://github.com/gubenkoved/amqp-test.

Below is the capture results, I've colored sender/receiver TCP streams as red/green.

According to this section of the Azure Application Architecture Guide, Azure Service Bus consumers use a poll model when talking to Azure Service Bus:

> Pull model
>
> A consumer of a Service Bus queue constantly polls Service Bus to check if new messages are available. The client SDKs and Azure Functions trigger for Service Bus abstract that model. When a new message is available, the consumer's callback is invoked and the message is sent to the consumer.

Since ServiceBusReceiver is such a consumer, it probably uses polling.