Le modèle de données (DM) d'un nœud n'est pas pertinent si nous ne pouvons pas effectuer d'opérations sur ceux-ci. Le modèle d'interaction (IM) définit la relation DM d'un nœud avec le DM des autres nœuds: un langage commun pour la communication entre les DM.
Les nœuds interagissent entre eux de différentes manières:
- Lire des attributs et des événements et s'y abonner
- Écrire dans des attributs
- Appeler des commandes
Chaque fois qu'un nœud établit une séquence de communication chiffrée avec un autre nœud, il s'agit d'une relation d'interaction. Les interactions peuvent être composées d'une ou de plusieurs transactions, tandis que les transactions sont composées d'une ou de plusieurs actions pouvant être interprétées comme des messages de niveau IM entre les nœuds.
Plusieurs actions sont possibles sur les transactions, telles qu'une action de requête de lecture qui demande un attribut ou un événement à un autre nœud, ou sa réponse, l'action de données de rapport, qui renvoie les informations du serveur au client.
Créateurs et cibles
Le nœud qui lance une transaction est l'initiateur, tandis que le nœud qui répond est la cible. Généralement, l'initiateur est un cluster client et la cible est un cluster de serveurs. Cependant, il existe des exceptions à ce format, comme dans les Interactions avec les abonnements analysées plus loin dans cette section.
Groupes
Les nœuds de Matter peuvent appartenir à un groupe. Un groupe d'appareils est un mécanisme permettant d'adresser et d'envoyer des messages à plusieurs appareils simultanément dans la même action. Tous les nœuds d'un groupe partagent le même ID de groupe, à savoir un entier de 16 bits.
Pour établir une communication au niveau du groupe (Groupcast), Matter utilise les messages Multicast IPv6, et tous les membres du groupe possèdent la même adresse Multicast.
Chemins d'accès
Chaque fois que nous voulons interagir avec un attribut, un événement ou une commande, nous devons spécifier le chemin d'accès de cette interaction: l'emplacement d'un attribut, d'un événement ou d'une commande dans la hiérarchie du modèle de données d'un nœud. La mise en garde est que les chemins peuvent également utiliser des groupes ou des opérateurs génériques pour adresser simultanément plusieurs nœuds ou clusters, ce qui agrège ces interactions et réduit ainsi le nombre d'actions.
Ce mécanisme est important pour améliorer la réactivité des communications. Par exemple, lorsqu'un utilisateur souhaite éteindre toutes les lumières, un assistant vocal peut établir une seule interaction avec plusieurs lumières au sein d'un groupe plutôt qu'une séquence d'interactions individuelles. Si l'initiateur crée des interactions individuelles avec chaque lumière, il peut générer une latence perceptible par l'humain dans la réactivité de l'appareil. Cet effet oblige les différents appareils à réagir à une commande avec des délais visibles entre eux. Ceci est souvent appelé "effet pop-corn".
Un chemin d'accès dans Matter peut être assemblé à l'aide de l'une des options ci-dessous:
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
Dans ces composants de base de chemin, endpoint et cluster peuvent également inclure des opérateurs génériques permettant de sélectionner plusieurs instances de nœud.
Chronométré et non chronométré
Il existe deux façons d'effectuer une transaction d'écriture ou d'appel: Timed (Temporisée) et Untimed (Non temporisée). Les transactions temporisées définissent un délai maximal pour l'envoi de l'action d'écriture/appel. L'objectif de ce délai avant expiration est d'empêcher une attaque par interception sur la transaction. Elle est particulièrement utile pour les appareils qui contrôlent l'accès à des ressources telles que les ouvertures de garage et les serrures.
Pour comprendre les transactions temporisées, il est utile de comprendre comment les attaques d'interception peuvent se produire et pourquoi elles sont importantes.
L'Attaque d'interception
Une attaque d’interception présente le schéma suivant:
- Alice envoie à Bob un message initial, par exemple une action de demande d'écriture.
- Eve, un homme du milieu, intercepte le message et empêche Bob de le recevoir, par exemple par le biais d'un brouillage radio.
- Alice, ne recevant pas de réponse de Bob, envoie un second message.
- Eve intercepte à nouveau et empêche Bob de la recevoir.
- Eve envoie le premier message intercepté à Bob, comme s'il provenait d'Alice.
- Bob envoie sa réponse à Alice (et Ève).
- Eve retient le deuxième message intercepté pour une relecture ultérieure. Comme Bob n'a jamais reçu le second message intercepté d'origine d'Alice, il va l'accepter. Ce message représente une brèche de sécurité lorsqu'il encode une commande telle que "open lock".
Pour éviter ces types d'attaques, les actions temporisées définissent un délai maximal avant expiration de la transaction au début de la transaction. Même si Eve parvient à exécuter les six premières étapes du vecteur d'attaque, il ne pourra pas relire le message à l'étape 7 en raison d'un délai d'inactivité expiré au niveau de la transaction.
Les transactions temporisées augmentent la complexité et le nombre d'actions. Elles ne sont donc pas recommandées pour chaque transaction, mais uniquement pour les opérations critiques sur les appareils qui contrôlent les éléments de sécurité et de confidentialité physiques ou virtuels.
Des abstractions de SDK
Les sections Lire les transactions, Écrire des transactions et Appeler des transactions fournissent une vue d'ensemble des actions du modèle d'interaction effectuées par le SDK.
Le développeur qui crée un produit qui utilise le SDK Matter n'effectue généralement pas d'appels pour exécuter directement des actions. Les actions sont extraites par les fonctions du SDK qui les encapsulent dans une interaction. Cependant, il est important de comprendre les actions de messagerie instantanée pour que l'ingénieur maîtrise les fonctionnalités de Matter et dispose d'un contrôle précis sur l'implémentation du SDK.