Насос сообщения служебной шины - это просто хорошая обертка вокруг существующей операции Receive. Я понимаю, что под капотом поток развернут для запроса сообщений из очереди с использованием стандартного метода Receive. Когда сообщение-сообщение получает сообщение, оно будет разворачивать поток и вызывать делегат OnMessage (до количества свойств одновременных вызовов в классе OnMessageOptions).
Что касается фактической связи насоса сообщений с служебной шиной, это зависит от connectivity mode. По умолчанию режим подключения для брокерских сообщений - это AutoDetect, но, как вы видите в комментарии в конце ссылки выше брокерского обмена сообщениями, не поддерживается возврат к HTTP из TCP, поэтому для обмена сообщениями он запускается через TCP и остается, если только вы явно установите его в HTTP.
В режиме подключения HTTP, если у вас есть correct ports open, вы можете видеть запросы от вызова Receive, и при длительном опросе вы можете увидеть, как он обновляет запросы. В режиме TCP (или по умолчанию, поскольку AutoDetect не возвращается к HTTP), он открывает TCP-соединение (на порте 9354) и использует это для двунаправленной связи. Вы можете увидеть это, если используете что-то вроде Process Explorer или NetStat.
На проприетарном протоколе, используемом служебной шиной, действительно недостаточно хорошей документации. Они поддерживают AMQP напрямую, открытый протокол обмена сообщениями, который проходит через другой порт. .NET library handles this, но вы определяете транспорт через соединительную строку или при создании MessagingFactory, установив TransportType на объект MessagingFactoryOptions.