Le modèle de données (DM, Data Model) d'un nœud n'est pas pertinent si nous ne pouvons pas effectuer d'opérations sur celui-ci. Le modèle d'interaction (IM, Interaction Model) définit la relation entre le DM d'un nœud et celui d'autres nœuds : il s'agit d'un langage commun pour la communication entre les DM.
Les nœuds interagissent entre eux de la manière suivante :
- Lecture et abonnement aux attributs et aux événements
- Écriture dans les attributs
- Appel de commandes
Chaque fois qu'un nœud établit une séquence de communication chiffrée avec un autre nœud, ils constituent une relation d'interaction. Les interactions peuvent être composées d'une ou de plusieurs transactions, et les transactions sont composées d' une ou de plusieurs actions, qui peuvent être considérées comme des messages au niveau de l'IM entre les nœuds.
Plusieurs actions sont compatibles avec les transactions, comme 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.
Initiateurs et cibles
Le nœud qui lance une transaction est l'initiateur, tandis que le nœud qui répond est la cible. En règle générale, l'initiateur est un cluster client et la cible est un cluster serveur. Toutefois, il existe des exceptions à ce modèle, comme dans les interactions d'abonnement 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 en même temps dans la même action. Tous les nœuds d'un groupe partagent le même ID de groupe, un entier de 16 bits.
Pour effectuer une communication au niveau du groupe (groupcast), Matter exploite les messages Multicast, et tous les membres du groupe ont la même adresse Multicast.
Chemins d'accès
Chaque fois que nous souhaitons 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. L'inconvénient est que les chemins d'accès peuvent également utiliser des groupes ou des opérateurs génériques pour adresser plusieurs nœuds ou clusters simultanément, en agrégeant ces interactions et en réduisant 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 d'un groupe au lieu d'une séquence d'interactions individuelles. Si l'initiateur crée des interactions individuelles avec chaque lumière, cela peut générer une latence perceptible par l'humain dans la réactivité de l'appareil. Cet effet fait que plusieurs appareils réagissent à une commande avec des délais visibles entre eux. On parle souvent d'"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 blocs de construction de chemin d'accès, endpoint et cluster peuvent également inclure des opérateurs génériques pour sélectionner plusieurs instances de nœud.
Avec et sans délai
Il existe deux façons d'effectuer une transaction d'écriture ou d'appel : avec délai et sans délai. Les transactions avec délai établissent un délai maximal pour l'envoi de l'action d'écriture/d'appel. L'objectif de ce délai est d'empêcher une attaque par interception sur la transaction. Cela est particulièrement vrai pour les appareils qui limitent l'accès aux ressources, comme les ouvre-portes de garage et les serrures.
Pour comprendre les transactions avec délai, il est utile de comprendre comment les attaques par interception peuvent se produire et pourquoi les transactions avec délai sont importantes.
L'attaque par interception
Une attaque par interception présente le schéma suivant :
- Alice envoie à Bob un message initial, tel qu'une action de requête d'écriture.
- Ève, un homme du milieu, intercepte le message et empêche Bob de le recevoir, par exemple par un brouillage radio.
- Alice, ne recevant pas de réponse de Bob, envoie un deuxième message.
- Ève intercepte à nouveau le message et empêche Bob de le recevoir.
- Ève envoie le premier message intercepté à Bob, comme s'il provenait d'Alice.
- Bob envoie la réponse à Alice (et à Ève).
- Ève conserve le deuxième message intercepté pour une relecture ultérieure. Comme Bob n'a jamais reçu le deuxième message intercepté d'Alice, il l'acceptera. Ce message représente une faille de sécurité lorsqu'il encode une commande telle que "ouvrir la serrure".
Pour éviter ces types d'attaques, les actions avec délai définissent un délai maximal pour la transaction au début de celle-ci. Même si Ève parvient à exécuter les six premières étapes du vecteur d'attaque, elle ne pourra pas relire le message à l'étape 7 en raison d'un délai expiré sur la transaction.
Les transactions avec délai augmentent la complexité et le nombre d'actions. Elles ne sont donc pas recommandées pour toutes les transactions, mais uniquement pour les opérations critiques sur les appareils qui contrôlent les ressources de sécurité et de confidentialité physiques ou virtuelles.
Abstractions du SDK
Les sections Transactions de lecture, Transactions d'écriture, et Transactions d'appel fournissent une présentation générale des actions du modèle d'interaction effectuées par le SDK.
Le développeur qui crée un produit utilisant le Matter SDK n'effectue généralement pas d'appels pour exécuter directement des actions. Les actions sont abstraites par des fonctions du SDK qui les encapsuleront dans une interaction. Toutefois, il est important de comprendre les actions de l'IM pour permettre à l'ingénieur de maîtriser les fonctionnalités de Matter et de contrôler l'implémentation du SDK.