Jump toUpdate content
Auto-provisioning allows your Hub to automatically onboard an unknown Device when that Device provides valid TLS credentials.
A client refers to any software connected to the IoT Hub. The software could be running on a connected device (firmware), an IoT Gateway or a server (application).
A Device is a representation of a client. Each Device that connects to the Hub is represented by a unique ID. The concept of Devices allows the Hub to authenticate clients and modify its behaviour towards each one appropriately. This includes the way the client connects to the Hub, the way messages are filtered and the way metrics are collected. See Understanding Devices for more information.
Device authentication ensures that only authorized Devices can connect to a Hub. To authenticate a Device, the Hub may use:
A Device certificate is a method of client authentication. A customer can provide any certificate for a specific Device. In this case, the certificate does not need to be signed by the Hub certificate authority.
Hub server certificate authority
Upon connecting to an IoT Hub using TLS, MQTT clients will be provided with a Hub server certificate. The client can verify this certificate using the Hub server certificate authority.
Hub certificate authority
This is the certificate authority the Hub will use to verify the certificate provided by a connecting client.
Hub Events may be understood as log entries for your Hub. They are triggered by events such as errors, security notices and auto-provisioning events, and then published on the Hub.
A connection is deemed insecure if mutual TLS is not enabled for it. This implies authenticating with a token, which is weaker than using a certificate. Devices may be configured to allow or deny insecure connections. If allowed, TLS and Plaintext are available. mTLS is always available.
Kickstarts are Scaleway Instances which are spawned, installed and configured for you to test and showcase some typical IoT use cases. Kickstarts are currently available for Data Visualization, Logging, Flow Programming and Function as a Service.
Last Will Message
When connecting, a client can provide a Last Will message to the Broker. This is a regular message which will be published by the Broker if the client disconnects unexpectedly. This mechanism allows clients to make sure other clients will be notified when they disconnect, whether properly or unexpectedly.
Messages are the base data transmission unit for IoT Hub. A message contains a payload (which can be any data) and a topic (which can be any string, and indicates what is in the payload). The Hub dispatches messages between connected clients.
IoT Hub is a message broker. It dispatches messages from publishers to subscribers (connected clients). With IoT Hub, subscribers receive a copy of published messages they are subscribed to. See Understanding Hubs.
Message filters restrict the messages a Device can publish or subscribe to. Each filter can be configured to allow or reject given topics.
Message Queuing Telemetry Transport (MQTT) is a lightweight publish/subscribe protocol for exchanging messages between Devices and/or applications. Find out more about MQTT on our blog.
Mutual TLS (mTLS)
Mutual TLS is a method of mutual authentication. It indicates that both the TLS client and TLS server are required to authenticate each other. Each party must therefore possess a certificate to provide to the other, as well as a certificate authority to verify the certificate provided by the other party.
Networks are the front doors to a Hub. Each Network supports a different protocol to exchange messages with the Hub. See Understanding Networks for more information.
The publish/subscribe model (also known as pub/sub) provides an alternative to traditional client-server architecture. In the client-sever model, a client communicates directly with the application supposed to receive the information. The pub/sub model decouples the client that sends a message (the publisher) from the client or clients that receive the messages (the subscribers). The publishers and subscribers never contact each other directly. In fact, they are not even aware that the other exists. MQTT is a publish/subscribe protocol.
Quality of Service levels (QoS)
Quality of Service level determines the reliability of the data flow between a client and a message broker. The message may be sent in three ways:
- QoS 0: the message will be received at most once (also known as “fire and forget”).
- QoS 1: the message will be received at least once.
- QoS 2: the message will be received exactly once.
Increasing the QoS level decreases message throughput because of the additional exchanges required between the client and the broker.
IoT Routes forward messages to non publish/subscribe destinations such as databases, REST APIs, Serverless functions and S3 buckets. See Understanding Routes for further information.
Transport Layer Security, and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. See also Mutual TLS.
A topic indicates what information is contained in a message. The message broker uses topics to forward published messages to the right subscribers. Learn more about topics on our blog.
Cloud Twins, or simply Twins, are virtual representations of your physical devices. Technically, they are JSON document sets stored in a Hub, recording data received from your Hub (eg data from device sensors, date/time information, desired state information and any other relevant data you wish to store). Each Device can have its corresponding Cloud Twin, which you can store and retrieve data to/from at any time. For more information, refer to our documentation about Cloud Twins.
WebSocket is a way for a browser to upgrade an HTTP connection into a somewhat “raw” TCP connection. By doing so, the HTTP server is now able to send data to the HTTP client without the client having to request it.