In Byteball, Every device connects to its home hub using websockets, that is, communication between every devices and between light client and full nodes is done by websocket
Then how can communication between full nodes implemented?
For storing all status of byteball in full nodes database, connection between full nodes should be existed.
What is the way to communicate between full nodes?
The communication between two wallets is done via the hub. The sender wallet sends the message to the recipient's hub and the hub forwards it to the recipient. If the recipient is not online, the hub stores the messages and forwards them when the wallet reconnects again. Note that the communication is encrypted end-to-end between the sender and recipient, the hub cannot decrypt messages passed between wallets.
Related
I am in the process of evaluating HONO for IOT stack. We have scenarios where an intermediary device would send telemetry data for other devices. Communication through an Intermediary device is referred as a Gateway in Hono. I have found how to send messages through Gateways.
I am not sure on the following queries.
How to register the Gateway? Should it be registered as an ordinary device or anything else should eb done?
How would Hono verify if the message is indeed sent from the device whose device ID is specified? Any option to authenticate the real sender of the message?
Yes, a gateway needs to be registered as a normal device with its own device ID and credentials.
In order for a gateway to be allowed to publish data on behalf of another device, that other device needs to have its via registration property be set to include the gateway's device ID. Example: your gateway device has ID GW1 and you have a device with ID DEV1. Then the registration information for the device should look like this:
{
"via": [ "DEV1" ],
...
}
When the gateway then connects to the adapter and is successfully authenticated, it can publish data on behalf of another device by means of indicating the device ID in the URI, topic, address as described by the user guides of the adapters. The adapters then verify, if the gateway ID is listed in the device's registration information's via property and if not, rejects the data. The adapter thus delegates authentication of the device to the gateway.
Pretty simple scenario.
A message gets published on a topic (by a master device), to which no clients are currently subscribed.
I am hoping messages published can have a custom expiry time.
So say within this expiry time, a client now connects to this topic.
How would this client receive the message published earlier?
What i am hoping to get as an answer, if it is possible and if so, what does AWS IOT provide to achieve the same.
Overall, above answer of #sanket has been true, with one change as follows:
Right now, AWS IoT supports MQTT persistent sessions. Please see following relevant snippet from AWS.
"Persistent sessions store subscription information and pending Quality of Service (QoS) 1 messages in case your devices become disconnected. When a device reconnects, its persistent session resumes and its subscriptions are automatically reinstated. Also, any stored messages are delivered."
Moreover, "Persistent sessions have a default expiry period of one hour. The expiry period begins when the message broker detects that a client disconnects (MQTT disconnect or timeout)."
Reference - How does a newly connected client get old messages in AWS IOT
With Any Standard MQTT Broker
You should connect the client with the broker using clean_session flag as False so that after this the broker will maintain your state with itself.
Refer this:- https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/
This document will fulfill your all queries.
NOTE:
As per standard MQTT spec, above-mentioned rules should be followed by MQTT broker but AWS-IoT broker does not follow this.
AWS-IoT message broker does not support persistent sessions (connections made with the cleanSession flag set to false). The AWS IoT message broker assumes all sessions are clean sessions and messages are not stored across sessions. If an MQTT client attempts to connect to the AWS IoT message broker with the cleanSession set to false, the client will be disconnected.
Possible Solution:
AWS-IoT provides something similar to cleansession flag using DeviceShaddow functionality.
AWS Device Shadows
The IOT Core Message Broker supports Persistent session expiry period. By default the messages associated with the session will be stored for 1 hour in case of session disconnects:
The duration for which the message broker stores an MQTT persistent session. The expiry period begins when the message broker detects the session has become disconnected. After the expiry period has elapsed, the message broker terminates the session and discards any associated queued messages. You can adjust this to a value from 1 hour to 7 days by using the standard limit increase process.
Each time that a new device connects to an IoT agent, the IoT agent sends an updateContext to the context broker and a new context entity is created. And if this device has some lazy attribute the IoT agent will send a contextentityRegistration in order to create a context registration, to indicate to the context broker how can connect to the device.
But when the Context Registration is created, I'm not sure about the value that will be assigned to the providingApplication attribute.
It is used the ip:port of the IoT agent where it listens to the context broker requests?
or should it be the URL of the device?
Although I'm not sure, I believe the correct one it's the first option, because the device normally won't understand the NGSI protocol, and the IoT agent should translate the request before sending it to the device. If that's the case, then:
It is necessary some initial configuration, or when the IoT agent creates a new context Registration automatically establishes itself as the context provider?
Regarding the property "commands" used when a new device is registered by the IoT agent, what's their functionality? Are they used by the IoT agent to translate any request from the context broker addressed to the device?
Thanks in advance, any help would be grateful.
2) The property "commands" is used to define attributes of the ContextBroker entity that will actually tirgger a command to the device if they are updated using the NGSI API. This means tahta developers are able to read observations and also send commands just using one API (NGSI) with no knowledge of the specific device technology or protocol.
1) In UL2.0 lazy attributes are not supported so far. Please refer to the other IoT Agents for that.
Normally the IoT Agent IP:Port should be used for that.
Cheers,
I am using Azure Notification Hubs to manage my device registrations.
I am using Azure Mobile Services to push notification request to Notification Hub.
Using tags, I am able to use notification hub to broadcast sender's message to a group of recipients.
My new requirement is, I want sender to be able to send notification to a particular device that belongs to a particular tag. Which means I need a way for sender to list all devices that is registered to, say... "football" tag, have sender choose which device to send to, and tell Notification Hub to send notification to that device.
How do I achieve that? I will need to write an api that returns all devices that belong to a certain tag to the sender right?
Notification Hubs allows users to extract all registrations associated with a single device. Take a look at https://msdn.microsoft.com/en-us/library/azure/dn223274.aspx, that should help.
For a startup considering making public notifications intended for website users available via a Pusher channel, how do you prevent people from subscribing to that channel for a long period of time (camping essentially)? I know you can disconnect users after a period of inactivity if they are connected from a web client (by checking for activity on the client and sending a disconnect after a period of inactivity), but what if users decide to connect via a command-line app or something similar?
Pusher provides private channels where the subscription to those channels need to be signed using your application secret in order for the subscription to be allowed.
Given the command-line app example you've provided the author of that application would not know the application secret and would therefore not be able to subscribe to the private channel.