0

I have currently upgraded to "Azure.Messaging.ServiceBus" from the legacy SDK. There was this option "ServiceBusEnvironment.SystemConnectivity.Mode" that can automatically detect amqp or https depending on the port's permission(5671 or 443). There is no such feature in the latest SDK as confirmed in this link. I now want to emulate the same feature using the latest library. However, in my network's firewall, if the outbound 5671 is denied, the exception is that the host was not found but in reality the host was there but couldn't be reached over 5671. Is there any other way to do this? Only if the 5671 is blocked by the windows firewall am I getting the socket exception which I can catch and attempt reconnection with https. This is not the same case if windows firewall allows but the underlying network blocks it. Any ideas?

Arun Prakash Nagendran
  • 411
  • 4
  • 18
  • Does this answer your question? [Cannot connect to Azure ServiceBus with Microsoft.Azure.ServiceBus](https://stackoverflow.com/questions/50764285/cannot-connect-to-azure-servicebus-with-microsoft-azure-servicebus) – Ecstasy Apr 11 '22 at 08:27
  • [Managing Azure Service Bus When TCP Port 5671 Is Blocked](https://cerebrata.com/blog/managing-azure-service-bus-when-tcp-port-5671-is-blocked), [Open outbound port requirements and IP address whitelisting](https://techcommunity.microsoft.com/t5/messaging-on-azure-blog/open-outbound-port-requirements-and-ip-address-whitelisting/ba-p/370828) and [AMQP 1.0 in Azure Service Bus](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide) – Ecstasy Apr 11 '22 at 08:33
  • @DeepDave-MT: I was aware that the auto-detect feature was not available in the latest SDK and I need to set the transport by myself. But the question is not that. My question was on the inputs on how to attain the same feature on the developer's part. – Arun Prakash Nagendran Apr 11 '22 at 08:37
  • You can't OOTB with the SDK. The latest SDK doesn't have this capability. – Sean Feldman Apr 11 '22 at 13:50

1 Answers1

0

The clients in Azure.Messaging.ServiceBus communicate only using the AMQP protocol. By default, connections are made using TCP sockets directly for efficiency. Unless you have explicitly set the TransportType in the ServiceBusClientOptions when creating your ServiceBusClient, that's what you're using.

The aforementioned TransportType allows you to request AMQP over web sockets, which is typically used to help work around firewall issues such as you're describing. The ServiceBusClientOptions also allows you to set a web proxy to route traffic through, should your environment require that.

Jesse Squire
  • 6,107
  • 1
  • 27
  • 30
  • Jesse, that's not what the question is about. The OP is asking about transport auto-detection. – Sean Feldman Apr 11 '22 at 13:52
  • @SeanFeldman: Thank you for clarifying the question to Jesse Squire. I was thinking to use "TcpClient client = new TcpClient("abc.servicebus.windows.net", 5671);" while creating the ServiceBusClient and if this fails, then switch to AmqpWebSockets. What do you think? Using the "TcpView" utility I was able to confirm that the remote 5671 with the SB was opened. – Arun Prakash Nagendran Apr 12 '22 at 04:52
  • Jesse, I am doing an in-place software upgrade for our customers. Previously, the connectivity mode was auto-detected to suit any port of theirs and with the new Azure SB SDK, this is not possible forcing me to go through a barrage of formalities with the network team to change firewall rules for 5671. Also, you may argue I can go with AmqpWebSockets. That again asks for 443 port opening with customers using 5671. Another option is to give a configurable setting for the customers to select. None of the option seems to be seamless as auto-detect. – Arun Prakash Nagendran Apr 12 '22 at 05:05