Currently, I am using Raspberry Pi on which I am hosting mosquitto MQTT broker and a separate C application that connects and subscribes to localhost. It is a wrapper of what I actually needed.
I actually need an MQTT broker running inside a C application from where I can control what client IDs can connect. Is there any way to achieve it?
Mosquitto provides a plugin interface that allows you to control which clients can connect and which topics they can publish/subscribe to.
Normally you would not control access by client id as this can be easily spoofed, instead you should probably be using username/password (or client certificates) to identify the clients.
There are example plugins that store this information in a database so it can be updated dynamically
Related
Can you explain how to make connection between Hbbtv React App in TV and mobile App in React Native?
I implement SSDP Client in React Native Mobile App to look for SSDP Server (That should be implmented on TV). Then receiving IP Address of that Server (Like in DIAL Architecture). Server also creating WebSocket Server. This server should start Hbbtv App that is written in React.js.
Now I can send messages from Mobile App to Hbbtv React App through this server, but I have no idea how to implement this kind of SSDP+WebSocket server on my TV.
This project https://github.com/fraunhoferfokus/cordova-plugin-hbbtv provides a good example and may answer your question. It is a cordova plugin for Android, but gives you an overview how to implement the Client for framework like React Native. The Hello World Mobile application in https://github.com/fraunhoferfokus/cordova-plugin-hbbtv-helloapp/ provides an example to use the plugin to discover and launch on TV.
The HbbTV App is developed using Web Technologies like in your case React.js and uses WebSocket to establish a connection to the local WebSocket Server running on the HbbTV Terminal. This folder https://github.com/fraunhoferfokus/cordova-plugin-hbbtv-helloapp/tree/master/www provides an example of a simple HbbTV App using CS Features. You can take it as a reference for your react.js. The main file you need to follow is https://github.com/fraunhoferfokus/cordova-plugin-hbbtv-helloapp/blob/master/www/js/cs-app.js. I hope this help.
For successful communication, the Companion Screen application should be on the same home network as the HbbTV terminal (TV Set).
The terminal (TV Set) implements the server providing endpoints that provide the server-side of the Websocket protocol for clients (HbbTV® application on the terminal and Companion Screen application).
The server shall be able to accept connections once an HbbTV® application on the terminal (TV Set) has called the getApp2AppLocalBaseURL() method of the HbbTVCSManager embedded object and until the application exits. Please see:
https://developer.hbbtv.org/references/apis/defined-javascript-apis/companion-screen-discovery-apis/
The terminal (TV Set) handles connection requests from clients (HbbTV® application and Companion Screen application) in the manner defined in clause 14.5.3 of the ETSI TS 102 796 standard and applies pairing rules defined in clause 14.5.4 of the ETSI TS 102 796 standard to determine whether to pair connections from two clients. It then acts as a relay, as defined in clause 14.5.5 of the ETSI TS 102 796 standard in order to relay messages between the two client connections that are paired.
In a nutshell, the HbbTV® application on the terminal (TV Set) connects to the server on the terminal (TV Set) and the connection enters a waiting state.
At this point, the Companion Screen application should connect to the server on the terminal and the connection enters a waiting state.
The terminal (TV Set) shall pair two waiting connections according to the following rules:
One waiting connection shall be on the local service endpoint (and
therefore be inferred to have come from the HbbTV® application
client).
One other waiting connection shall be on the remote service
endpoint (and therefore be inferred to have come from a remote
client, such as a Companion Screen application).
The app-endpoint portion of the resource name used in the client handshake request shall match between both waiting connections.
This "tactic" should give you the desired result.
I have a backend microservice that is using MassTransit and RabbitMQ to publish some messages. I am interested in implement a solution to relay those messages to my app's front end which is written in ReactJS.
I have researched online on various tutorials, most of them show me how to use a JavaScript rabbitMQ client to subscribe/connect to the service bus. But since it is wrapped in MassTransit, and the URL is in the format of "rabbitmq://...", how do I subscribe to this messaging host using Javascript? Ideally I would like to use a WebSocket connection, research tells me that I should consider either STOMP or MQTT, is that something I need to configure in my backend MassTransit/rabbitmq service?
My backend service also have some http endpoints that I can reach using a plain http/https URL, such as https://localhost:7179/api/doSomeJob. Will this help with my intention of using a WebSocket connection to subscribe to the MassTransit service bus?
I am working on an iot device using google-cloud-iot-core, but i would like to have allow for 3rd party support, so i want to change the host name of the mqtt, how can it be done?
Thanks in advance
If you change that endpoint, then you're no longer talking to IoT Core. It's not configurable, as that's the endpoint to talk to the service.
You can setup your own MQTT server somewhere else (could do it in GCE or GKE with a custom container) and make the hostname whatever you want, and then setup your own broker to take the MQTT payloads and create Pub/Sub messages, or even to act as a forwarding proxy to IoT Core itself I suppose (although security and auth might get a bit odd).
Or you could even just go directly to Pub/Sub. It all just depends on your need.
As I mentioned, changing the hostname for IoT Core (the mqtt.googleapis.com) it means that you aren't using IoT Core any longer. There's no other way to access the communication broker piece of IoT Core to do the Pub/Sub message creation, etc. If you don't use the IoT Core endpoint (hostname) then you'd be on your own for creating the Pub/Sub messages from the IoT device data.
I want my angular app to detect scanner and perform scanning functionalities? how will i get this functionality in my app?
That depends on the type of scanner you are using.
Most scanners connected to a network have an IP. You can login to the scanner at that IP to configure it. But they may not expose an API to send/receive instructions.
Browsers are not designed to connect with scanners. If you want to achieve this through the browser, you will need a server in the middle to receive instructions from client and pass them on to the scanner.
I am currently developing a C# Windows Form Application that I intend to let it interact with a server. The server will receive posting from a mobile application that I have developed and whenever a posting is received, my Windows Form Application should be notified and give me a notification.
E.g. My mobile application sends an posting over to my server. Once my server receives the message, my windows form application should display a new notification showing the content of the message received and updates the UI accordingly.
In this type of scenario, it is better to use duplex WCF service or the just the regular WCF service?
If duplex, mind explaining why do I need to use duplex service? Thanks!
A duplex service is a service where two channels are created.
The first channel is the ordinary client -> server channel using your service contract. This is what you'll find in every WCF service, and is how your client can send a request to the service and it can respond.
The second channel is a server -> client channel using a different service contract that you define. This second channel is how the server can send messages to the client without the client requesting them.
In your scenario, you seem to indicate that an event taking place on the server should send a message to your client. If this is the case, then yes, you need a duplex service so that the second channel exists, which allows the server to notify your client without the client initiating a request.
Working on the assumption that your Windows app and your server are one the same domain I would suggest you use a publish/subscribe pattern for this type of interaction. You could use something along the lines of the IDesign sample which is available on their website. Essentially your Windows app is subscribing to events which are generated by your mobile application sending a posting to your server. Your publisher will then push the event to your Windows application.
To accomplish this your connection to the server/publisher needs to be always open. This is best achieved with tcpBinding as it is bi-directional and allows you to set high timeouts (effectively infinity).
If you cannot use TCP then your job has become a little harder. Using a duplex channel is a little problematic because you have to monitor the channel as well, because neither side will notifiy the other if the channel closes. You will only find out when you try to use it. This can still happen with the TCP connection of course but its a bit more stable that using http.
The other alternative is to use MSMQ binding. This will guarantee the delivery of your message because you are interacting via MSMQ rather than a communication channel such as http or tcp. In this instance you wouldn't even need the pub/sub framework, you could just have the service that receives your mobile posting send on a message to the queue, which your Windows application is monitoring. The upside to using the framework is that you can have multiple applications listening for the same event.
HTH.