can pubsub.azure.servicebus.topics control connection type?

[MarkClouden]

Scanning the code base i do not find any way to specify that the servicebus client be created with the AmpqWebSockets transport type.

I dont think that this is possible via metadata for the component, but wanted to double-check.

We are not able to connect for pub or sub via Dapr from an on-prem component due to firewall restrictions. But I can code up my own subscriber and make this connection outside of Dapr by specifying the client options transport type as AmpqWebSockets.

Obviously I would have preferred having the ability to control this with pubsub component spec, but possibly there are design reasons that this is not the case. If not, I can re-raise this as a feature request.

[berndverst]

Dapr does not support websockets in general (anywhere) at this time.

We use this SDK in our implementations of service bus components. https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/messaging/azservicebus/README.md

There seems to be a websockets example: https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/messaging/azservicebus/example_websockets_and_proxies_test.go

How would you expect this feature to work? Provide a websocket URL accessible to daprd (so must be localhost) in the form of wss://localhost:$SOMEPORT/socketserver ?

The Dapr runtime does not support websockets, so if we implemented this websocket support in this component this would bypass a lot Dapr features like Deadletter Queues, retries, dropping of messages etc.

It does not seem likely that we can actually implement this.

[berndverst]

Adding @ItalyPaleAle for his thoughts / input (note he's out for 2 weeks).

[berndverst]

I'll add this to the 1.13 milestone - not as a commitment this will get worked on, but to make sure we don't forget this discussion.

[MarkClouden]

Sorry, possibly some confusion - I refer only to the pubsub component and its ServiceBus connection.

I can only reference the C# ServiceBusClientOptions type, and its Azure.Messaging.ServiceBus.ServiceBusTransportType property. The default for this is AmqpTcp, but AmqpWebSockets is an option as well. In our scenario, only connections made with transport type AmqpWebSockets is possible.

I only ask that this be a configurable choice that may be used for the servicebus client options.

Something like

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: servicebus-pubsub
spec:
  type: pubsub.azure.servicebus.topics
  version: v1
  metadata:
  # Required when not using Azure AD Authentication
  - name: connectionString
    value: "Endpoint=sb://{ServiceBusNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={ServiceBus}"
  - name: transportType
    value: [ amqpWebSockets | amqpTcp ]

And having the transportType utilized in the servicebus client options at create

[berndverst]

This is not supported today and must be implemented as a feature.

A good starting point: https://github.com/Azure/azure-sdk-for-go/blob/5f029fd307e2b078175c29bf09667a19f26fbf53/sdk/messaging/azservicebus/example_websockets_and_proxies_test.go#L6-L39

In short, the AMP transport type must be exposed as a new component metadata property, say transportType with values tcp (the default) and websockets.

If the value is set to websockets the websocket connection info must be set on the client options.