Does Azure Event Hub consume UDP packets? I want to utilize Azure Event Hubs but it seems limited to only TCP.
As far as I know, to send the data to Event Hubs, developers must publish the events via the AMQP or the HTTPS. UDP is a connectionless protocol, it seems not support in Azure Event Hubs.
For detailed information about Event Hubs protocol, please refer to this article: AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide.
Related
I'm tryng to develop an high-frequency message dispatching application and i'm observing for the behavior of the SDK about message reading from the ModuleClient connected to the edgeHub by using "MQTT on TCP Only" transport settings.
Seems that there is no way to read multiple messages at time (batch) from the edgeHub (I think is something related to the underlying protocol).
So the result is that one must sequentially read a message, process it and give the ack to the hub.
Does exist a way to process multiple message at time without waiting for the processing of the previous?
Is this "limitation" tied to the underlyng protocol?
I'm using Microsoft.Azure.Devices.Client 1.37.2 on a .NET Core 3.1 application deployed on Azure Kubernetes (AKS) by using Azure IoT Edge on Kubernetes workload.
You are correct, you cannot use batch in MQTT protocol. This is a limitation tied to IoTHub when using MQTT Protocol.
IoT Hub only supports batch send over AMQP and HTTPS at the moment.
The MQTT implementation loops over the batch and sends each message
individually.
Ref: https://github.com/Azure/azure-iot-sdk-csharp
Suggest that you add a new feature request, if need IoTHub to support batch when connecting using MQTT: https://feedback.azure.com/forums/321918-azure-iot-hub-dps-sdks
I can see that it's possible to send messages from RabbitMQ to Azure Service Bus - see here.
Wondering if it's possible to do the reverse i.e. send messages from Azure Service Bus to RabbitMQ? Essentially trying to integrate with third party...
I have sent messages to Azure IoT Hub device called dev1, I could not see the messages in IoT Hub but, I can read the messages only when the client application is online when the sender is sending messages. Azure IoT Hub supports only online messaging and no offline messaging? If offline message support is there, where are these messages are stored, I couldn't see the messages in IoT Hub.
When I configure the custom endpoint as Blob storage, I can see messages are stored in blobs.
Please help me on this.
Thanks in advance
If I understand correctly you are looking for reading the messages directly on IoT Hub portal UI. If that is the case, then one of the things which you can make sure about D2C Messages in IoT Hub portal (UI perspective) is looking at the Metrics chart (See below Images). For reading the actual payload you have to make use of in-built Event Hub endpoint or routing to other supported endpoints.(You have already mentioned in your scenario-Client/Sender applications, So I think you have already known this method of reading messages)
The Metrics chart atleast tells you that the messages are received in IoT Hub (UI), you can't read them on the Portal(UI).
IoT Hub is built on top of Event Hubs, and that's where your messages will be until you start reading them. They will be stored there for 1 day by default, although you can change that up to 7 days. For more information on retention, please read this page.
Is the use-case of the ServiceClient to send messages to devices?
ServiceClient supports only amqp messages. Documentation for Azure Devices namespace says "Transport types supported by ServiceClient - Amqp and Amqp over WebSocket only". In code the TransportType exposes only Amqp. Would it be changed in the future?
If the ServiceClient is been used for C2D messages, why in this answer, is written that "For ServiceClient, you need Azure IoT Hub connection string, not device connection string"?
What is the performance's impact and resources' utilization, if we hold a reference of the created ServiceClient object (or the Registry Manager)?
and what is the impact in case
when we open-close the connection?
when we leave open the conection?
Is the use-case of the ServiceClient to send messages to devices?
Yes. You need use ServiceClient to send C2D messages.
ServiceClient supports only amqp messages. Documentation for Azure
Devices namespace says "Transport types supported by ServiceClient -
Amqp and Amqp over WebSocket only". In code the TransportType exposes
only Amqp. Would it be changed in the future?
For future plans, you can reference this guide ask a question.
If the ServiceClient is been used for C2D messages, why in this
answer, is written that "For ServiceClient, you need Azure IoT Hub
connection string, not device connection string"?
Device connection string: Connection string based on primary key used in API calls which allows device to communicate with Iot Hub. It allows you to receive C2D messages, not send C2D messages. IoT Hub exposes its functionality to various actors, like per-device and service.
What is the performance's impact and resources' utilization, if we
hold a reference of the created ServiceClient object (or the Registry
Manager)?
You can check IoT Hub throttling and you and IoT Hub quotas and throttling for more detail.
I am looking in for the best way to implement the RabbitMQ consumer by using .Net Client which should be run as windows service.
I referred the RabbitMQ documentation and found the way to consume messages by using .Net client (https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html).
My current scenario is like, RabbitMQ is installed in AWS VM machine. I have to install dotnet client consumer service resides in On-premise network which should consume messages.
Which one is the best way, to always listen the Queue (AMQP protocol) or HTTP API which should get messages on demand (https://pulse.mozilla.org/api/).
Please advise.
Thanks,
Vinoth
I believe the answer is "neither." You should have your message queue as a back-end service behind the firewall, and expose your application functionality through a set of carefully-specified web services. The web services, which are exposed through the firewall but can communicate to services behind the firewall, would produce messages that would be transmitted to the server. Any services needing to produce or consume messages would need to do so via the web services, which would perform safety/security checking prior to forwarding the request on to the AMQP server.
If you need to expose AMQP directly to clients (i.e. that is the purpose of your app), then the recommendation is to do so via STOMP. I think a valid use case for exposing AMQP directly over the internet would be a rare thing to come across. The security implications of doing so would be immense.