I'm considering trying the MQTT implementation provided by Qt.
I've studied the documentation, the classes, the members of the classes, and the examples. Nowhere did I find anything indicating how to make my own broker.
All the examples, and all the classes and the available source code seem to be limited to creating a client. The examples use some online broker service to test this client.
So, does the Qt MQTT package provide an easy way of writing my own broker?
No, it is for clients. The overview pretty much says so
It enables applications to act as telemetry displays and devices to publish telemetry data.
Related
I will be asking a very subjective question, but it is important as I am looking to recover from failure to effectively use BlueZ programatically.
Basically I envision an IoT edge device that runs on a miniature computer (Ex: Raspberry pi or Intel Compute Stick). The device would then run AlpineLinux OS and interact with Cloud.
Since it is IoT environment, it is needless to mention the importance of Bluetooth BLE over ISM band. Hence the central importance of being able to customize and work with BlueZ.
I am looking to do several things with BlueZ BLE including but not limited to
Advertising
Pairing
Characteristic
Broadcast
Secure transport of data etc...
Since I will be needing full control over data, for data-processing and interacting with cloud (Edge AI or Data-science on Cloud) I am looking at three ways of using BlueZ:
Make DBus API calls to BlueZ Methods.
Modify BlueZ codebase and make install a custom bin.
(So that callback handlers can be registered and wealth of other bluez
methods can be invoked)
Invoke BlueZ using command line utils like hcitool/bluetoothctl inside a program using system() calls.
No 1 is where I have failed. It is exorbitant amount of effort to construct and export DBus objects and then to invoke BlueZ methods. Plus there is no guarantee that you will be able to take care of all BLE issues.
No 2 looks very promising and I want to fully explore how feasible it is to modify the BlueZ code to my needs.
No 3 is the least desirable option, but I want to have it as a fallback option nevertheless.
Given my problem statement, what is the most viable strategy forward? I am asking this aloud so that I do not make more missteps and cost myself time and efforts.
Your best strategy is to start with the second way (which you already found promising) as this is a viable solution and many developers go about this method in order to create their BlueZ programs. Here is what I would do:-
Write all the functionality of the system in some sort of flowchart or state machine. This helps you visualise your whole system and what needs to be done to reach your end goal.
Try to perform all the above functionality manually using bluetoothctl and btmgmt. This includes advertising, pairing, etc. I recommend steering away from legacy commands such as hcitool and hciconfig as these have been deprecated and have a very different code structure.
When stumbling upon something that is not the default in bluetoothctl/btmgmt or you want to tweak the functionality, update the source to do so.
Finally, once you manually get the system to perform the functionality that you need (it doesn't have to be all, it can just be a subset of the functions), you can move to automating the whole process. This involves modifying the source for bluetoothctl/btmgmt commands so that instead of manual intervention, everything would be event-driven.
This is a bonus, but if you can create automated tests using python or some other scripting language, then this would ensure that your system is robust and that previous functionality doesn't break when adding new ones.
By the end of this process, you'll have a much better understanding of the internals of bluetoothctl/btmgmt and D-BUS APIs that you might be able to completely detach your code from the original bluetoothctl/btmgmt or create the program from scratch.
You probably already know this, but when modifying the tools, this is the starting point for the source code:-
bluetoothctl - client/main.c
btmgmt - tools/btmgmt.c
For more references on using bluetoothctl commands and btmgmt, please see the links below:-
BlueZ D-Bus C or C++ Sample
Bluetoothctl set passkey
https://stackoverflow.com/a/51876272/2215147
Bluez Programming
Linux command line howto accept pairing for bluetooth device without pin
https://stackoverflow.com/a/52982329/2215147
Bluetooth Low Energy in C - using Bluez to create a GATT server
I hope this helps.
I am looking for a snip of code in Blackberry 10 that my device is connected with n/w or not.
The official way is the Wi-Fi Service API, if you're familiar with C you should be good to go, look for any BPS tutorial/code online.
The unofficial and easier way is my class WifiWatcher from TheUnexposedAPIs, this project is a collection of easy-to-implement C++ classes that makes available all kind of internal objects from PPS (not to be confused with BPS).
You'll find an example of how to use it in QML in the project.
How to integrate other languages than those from .net world? For example to access messages from the bus in Java or C++? Do I have to listen to the queue in the backend instead? Is there a common Api provided by Rebus?
While Rebus may market itself as a "service bus"(*), it is actually more a kind of a "driver" with a common abstraction that enables .NET programmers to use various queues and persistence technologies without worrying too much about the specifics.
As such, Rebus cannot really be connected to, much as you would not be able to connect to, say, the NpgsqlConnection or the SqlConnection you would use to communicate with your Postgres or SQL Server database.
What you could do, was to interface with Rebus at the transport and/or persistence level, e.g. by using the same wire-level format when exchanging messages.
This would require that the chosen transport (MSMQ, RabbitMQ, SQL Server, etc.) can be interfaced with from the desired platform, and then you would need to be able to supply the correct headers for Rebus to accept the message as valid.
There is no official Rebus implementation for any other platforms besides .NET (.NET 4.5 + .NET Standard 1.3).
To my knowledge, no one has attempted to actually build a Rebus-compatible messaging library on any other platform.
(*) I actually usually use the word "messaging library" to describe it, because I think it carries way less confusion and semantic overload with it.
Yes. I think we need to know a minimal message format that an application for example PHP can compose and send directly to an endpoint queue. That would make life easy in certain cases.
Hi went through Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.
http://www.eaipatterns.com/toc.html
I also went through Camel and Mule's compliance with these integration patterns -
http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule
http://camel.apache.org/enterprise-integration-patterns.html
I see that both Mule and Camel allow applications to be deployed and accessed via webservices like SOAP or REST, SOAP being more RPC style. They allow massive integration support using opensource utilities like CXF and Jersey. In fact Mule also supports RMI endpoints - which will give remote method invokation capability as well which is a well-accepted form of Integration.
I understands ESBs are built around a Message Bus with additional support for other protocols however ESBs only comply to EIP and EIP is not just ESBs.
Question is why SOAP/REST or their transport protocol not considered as "Integration Styles" and which is Enterprise Integration so "Message Oriented"?
I am a novice compared to the great minds which designed these patterns but trying to understand the lopsided message-y nature of Integration patterns. I admit it isn't quite the QnA format of stack overflow but will request Mods to keep it alive for a while so that people can share their opinions.
As for SOAP, it would put it under the Integration Style "Remote Procedure Invocation", since it's pretty much what SOAP implements in reality (I won't consider the SOAP over JMS hybrids here with a potential to mix RPC with Messaging..).
REST is, interface wise, very different from SOAP in that it's resource driven instead of service driven. I would non the less group it under the "RPC" style since it's just another format of syncrhonous RPC calls.
I would, however, not put too much effort in theory of what EIP integration style a specific message pattern implements.
Look at a specific scenario at hands instead and use the EIP to model your specific integration.
I've seen integrations of file transfers that in realtiy implemented RPC patterns or SOAP services that in reality implemented messaging (although I don't really recommend do this).
A concrete example: consider the usage of a dedicated file upload service, which happends to be built using SOAP technolgy, which uploads a CSV file to a file area on a server, from where it's picked up by some other system. I would call this file based integration on a high level.
Another example is that Messaging systems sometimes are implemented using a shared database. Still the integration style using them is messaging, not "Shared Database".
Think about how your integration should work on a high level, then apply the various protocols to do the grunt work.
I have a system where clients connect via http streaming channels and use Producer and Consumer classes to dispatch and receive messages. I need to test the latency of messages in a way that adequately simulates real-world usage when the server is under load. I have 3 ideas for how this may be accomplished. Has anyone tried and succeeded or failed with these methods?
Use an out-of-the box test system like JMeter. Haven't found any that support streaming yet.
Use Selenium and FlexMonkey on BrowserMob to simulate actual users.
Use a client api (possibly from BlazeDS) that supports streaming and Flex messaging to write a custom testing framework. Haven't found a client api that supports streaming yet, any language would be OK.
There is a tool for testing the performance of BlazeDS/LCDS, created by Adobe. Take a look here (there is a PDF file called Adobe LiveCycle Data Services 3 ES2 Performance Brief in the PDF portofolio, having a couple of attachments) .