For simplicity, let's consider Microsft's tutorial for creating a module: https://learn.microsoft.com/en-us/azure/iot-edge/how-to-visual-studio-develop-module?view=iotedge-2018-06
Through this tutorial, we learn to listen to messages routed to the edge hub via the SimulatedTemperatureSensor.
I have taken this a little further where I registered an additional device, myAwesomeDevice (which is a console app that creates messages similar to SimulatedTemperatureSensor). myAwesomeDevice now ships x messages to the edge hub. I have added an additional route to the aforementioned tutorial that listens for messages from myAwesomeDevice and sends them into a BrokeredEndpoint.
What I want to accomplish now, if it is possible, is to have myAwesomeDevice be able to receive messages from the module created in the tutorial. Let's imagine myAwesomeDevice is now software that displays to the user running the software all the temperature metrics. Is it possible for this module to send that message to myAwesomeDevice?
I have begun to head down the SetMethodHandlerAsync as a direct message approach, but am struggling to grasp if 1) this is correct 2) how the device receives the message
I was able to achieve this with the InvokeMethodAsync method on ModuleClient.
Related
I know that using MQTT topics devices can subscribe to them. But is there any way that a IoT device can send some message to a target IoT device (by device id or something) without using a topic or is there any standard topic for this scenario?
There is no way to communicate without a topic, but you can create a topic for any purpose. So typically if you wanted to send a message to another client, you would publish it somewhere in the hierarchy of topics to which that client is subscribed.
That could be as simple as something like device/12345/inbound or whatever you prefer. And because topics can have hierarchy, in addition to whatever detail you put in the body, you can also encode categorization of your message into the topic, much as RESTful APIs often do in a URL.
A good reason for using target-specific (or owner-account-specific) topics is that the most easy solutions for MQTT security compartmentalization are topic-scope.
I'm working on the front end development of a custom mail system and at this point I've been using simple HTML to display data based upon my own received e-mails, however now I would like to create a table in my database of the information which is received upon connecting from on POP3/iPOP server.
Using Outlook.com you can rigth-click a mail and view source however I am oblivious to as whether this is the information gathered upon connecting.
I'm hoping this is the sort of question I can ask on here, basically I'd like to have an answer showing one example of all information received from the iPOP/POP3 server with information and/or useful resources.
To Clarify
I'm working on the front-end development and would like realistic information that would be gathered to create a dummy database table, thus meaning I can echo the information and create functions and whatnot prior actually establishing a connection to POP3 or iMAP
POP is a classic internet protocol in that it contains lots of plain text. You can use POP effectively using just telnet server.doma.in 110 to see how a server responsds to a particular command, and Wireshark will dump the commands user by Outlook and the server's responses, both in a format that'll suit your tests well.
I'm in search of a RELIABLE websocket server for ROR 3.Now we're using socky. It is unreliable. We like it because it has flash fallback, so it suppose to work on older browsers...but again - it is unreliable.
Do you know any good websocket server for ROR with fallback (i.e. supporting all browsers)
alternatives are:
socket.io (raw Websocket for NodeJS)
juggernaut (Complete Bayeux Protocol for NodeJS/Rails)
faye (Complete Bayeux Protocol for NodeJS/Rails) with a Ruby-Server
A tip: don't use ruby as websocket server, go for NodeJS - we handle thousands of messages every hour without any issue.
We used the most simple setup possible to make it work - and it works ;)
Our Setup:
Rails 3.0.9
Redis
NodeJS
Socket.IO
How we set it up:
Rails --PUB--> REDIS --SUB--> NodeJS --WEBSOCKET (SOCKET.IO)--> Client
Article Redis PubSub - How does it work?
Another tip: Avoid authentication if possible
Here's our case:
We have something like a project management tool with a virtual filesystem. Let's say you're viewing a folder while someone else of your team uploads a new file. Now we have to inform you that your view is out of the date - we send a message like:
folder_id | last_change_timestamp
to the channel folders:#{folder_id}
now the client (which listens to folders:#{folder_id} receives that messages and sees "whoops my view is out of date" and shows a message "Your view is outdated, please click >here< to refresh".
The good thing is that we don't need any authentication because:
if you have no access to the project you would have to guess the folder_id to subscribe to the channel
even if you manage to subscribe to the channel the only information you get is that something has changed - not more not less ;)
are there anyone hear about APE (Ajax Push Engine) before ? I'm building Rails application and trying to create group chat with this APE realtime engine, the problem is how to make Rails communicate with APE Server ? Are there any tutorial or reference on working APE with Rails ?
As far as I know, Mike's answer is not entirely correct.
For clients all clients the receiving part, in all scenarions, this is 100% correct: The communication is done by Javascript.
Also, the javascript can (and in many cases will be the best choice) be the most reasonable choice to push the info to the server too. This is the case with open communications of many to many people like in chat rooms.
However the following documentation page states clearly that we have other choices:
"Using inlinepush module to push data
from your php/rails/python/...
application to APE"
http://www.ape-project.org/wiki/index.php/Tutorial:How_to_write_an_application_with_APE
There are many cases that this could and should be so. I can think of at least 2 scenarios:
Applications that only logged in users could post things to others. Your app would handle the login and inline push info to the ape server.
Applications that broadcast live information from one source to many clients (in this case only the admin could post and this configuration is done on the server side also.
Let me note that I'm not using APE yet, I'm researching it and if I find I've posted any misleading info here, I'll come back and correct myself.
The short answer is that "you don't" APE works with Javascript calls back to the APE server (typically proxied through Apache or whatever server you're using).
Conceptually, if you wanted to break out into different "rooms" or whatever, you'd setup defaults within the javascript from the rails settings.
I am to build a web application which will accept different events from external sources and present them quickly to the user for further actions. I want to use Ruby on Rails for the web application. This project is a internal development project. I would prefer simple and easy to use solutions for rapid development over high reliable and complex systems.
What it should do
The user has the web application opened in his browser. Now an phone call comes is. The phone call is registered by a PBX monitoring daemon. In this case via the Asterisk Manager Interface. The daemon sends the available information (remote extension, local extension, call direction, channel status, start time, end time) somehow to the web application. Next the user receives a notified about the phone call event. The user now can work with this. For example by entering a summary or by matching the call to a customer profile.
The duration from the first event on the PBX (e.g. the creation of a new channel) to the popup notification in the browser should be short. Given a fast network I would like to be within two seconds. The single pieces of information about an event are created asynchronously. The local extension may be supplied separate from the remote extension. The user can enter a summary before the call has ended. The end time, new status etc. will show up on the interface as soon as one party has hung up.
The PBX monitor is just one data source. There will be more monitors like email or a request via a web form. The monitoring daemons will not necessarily run on the same host as the database or web server. I do not image the application will serve thousands of logged in users or concurrent requests soon. But from the design 200 users with maybe about the same number of events per minute should not be a scalability issue.
How should I do?
I am interested to know how you would design such an application. What technologies would you suggest? How do the daemons communicate their information? When and by whom is the data about an event stored into the main database? How does the user get notified? Should the browser receive a complete dataset on behalf of a daemon or just a short note that new data is available? Which JS library to use and how to create the necessary code on the server side?
On my research I came across a lot of possibilities: Message brokers, queue services, some rails background task solutions, HTTP Push services, XMPP and so on. Some products I am going to look into: ActiveMQ, Starling and Workling, Juggernaut and Bosh.
Maybe I am aiming too hight? If there is a simpler or easier way, like just using the XML or JSON interface of Rails, I would like to read this even more.
I hope the text is not too long :)
Thanks.
If you want to skip Java and Flash, perhaps it makes sense to use a technology in the Comet family to do the push from the server to the browser?
http://en.wikipedia.org/wiki/Comet_%28programming%29
For the sake of simplicity, for notifications from daemons to the Web browser, I'd leave Rails in the middle, create a RESTful interface to that Rails application, and have all of the daemons report to it. Then in your daemons you can do something as simple as use curl or libcurl to post the notifications. The Rails app would then be responsible for collecting the incoming notifications from the various sources and reporting them to the browser, either via JavaScript using a Comet solution or via some kind of fatter client implemented using Flash or Java.
You could approach this a number of ways but my only comment would be: Push, don't pull. For low latency it's not only quicker it's more efficient, as your server now doesn't have to handle n*clients once a second polling the db/queue. ActiveMQ is OK, but Starling will probably serve you better if you're not looking for insane levels of persistence.
You'll almost certainly end up using Flash on the client side (Juggernaut uses it last time I checked) or Java. This may be an issue for your clients (if they don't have Flash/Java installed) but for most people it's not an issue; still, a fallback mechanism onto a pull notification system might be prudent to implement.
Perhaps http://goldfishserver.com might be of some use to you. It provides a simple API to allow push notifications to your web pages. In short, when your data updates, send it (some payload data) to the Goldfish servers and your client browsers will be notified, with the same data.
Disclaimer: I am a developer working on goldfish.
The problem
There is an event - either external (or perhaps internally within your app).
Users should be notified.
One solution
I am myself facing this problem. I haven't solved it yet, but this is how I intend to do it. It may help you too:
(A) The app must learn about the event (via an exposed end point)
Expose an end point by which you app can be notified about external events.
When the end point is hit (and after authentication then users need to be notified).
(B) Notification
You can notify the user directly by changing the DOM on the current web page they are on.
You can notify users by using the Push API (but you need to make sure your browsers can target that).
All of these notification features should be able to be handled via Action Cable: (i) either by updating the DOM to notify you when a phone call comes in, or (ii) via a push notification that pops up in your browser.
Summary: use Action Cable.
(Also: why use an external service like Pusher, when you have ActionCable at your disposal? Some people say scalability, and infrastructure management. But I do not know enough to comment on these issues. )