Le modèle de données (DM) d'un nœud n'est pas pertinent si nous ne pouvons pas effectuer d'opérations dessus. Le modèle d'interaction (IM) définit la relation de DM d'un nœud avec le DM d'autres nœuds: un langage commun pour la communication entre les DM.
Les nœuds interagissent entre eux de la manière suivante:
- Lire et s'abonner aux attributs et aux événements
- Écrire dans les attributs
- Appeler des commandes
Chaque fois qu'un nœud établit une séquence de communication chiffrée avec un autre nœud, ils établissent 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 comprises comme des messages de niveau chat 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 création de rapports sur les données, 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 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 simultanément des messages à plusieurs appareils dans la même action. Tous les nœuds d'un groupe partagent le même ID de groupe, un entier 16 bits.
Pour effectuer une communication au niveau du groupe (Groupcast), Matter exploite les messages Multicast IPv6, 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 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 avec caractères génériques pour adresser plusieurs nœuds ou clusters simultanément, en agrégant 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 ampoule, il peut générer une latence perceptible par l'utilisateur dans la réactivité de l'appareil. Cet effet entraîne une réaction des différents appareils à une commande avec des délais visibles entre eux. On parle souvent de "effet popcorn".
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 d'espaces réservés pour 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: avec délai et sans délai. Les transactions temporelles établissent un délai avant expiration maximal pour l'envoi de l'action d'écriture/d'appel. L'objectif de ce délai avant expiration est d'empêcher une attaque par interception sur la transaction. Il est particulièrement valable pour les appareils qui contrôlent l'accès aux éléments, tels que les ouvre-portes de garage et les serrures.
Pour comprendre les transactions temporelles, il est utile de comprendre comment les attaques par interception peuvent se produire et pourquoi les transactions temporelles sont importantes.
Attaque par interception
Une attaque par interception se présente comme suit:
- Alice envoie à Bob un message initial, par exemple une action d'écriture.
- Eve, un pirate informatique, intercepte le message et empêche Bob de le recevoir, par exemple en utilisant un type de brouillage radio.
- Alice, ne recevant pas de réponse de Bob, envoie un deuxième message.
- Eve intercepte à nouveau le message et empêche Bob de le recevoir.
- Eve envoie le premier message intercepté à Bob, comme s'il venait d'Alice.
- Bob envoie la réponse à Alice (et à Eve).
- Eve conserve le deuxième message intercepté pour le lire plus tard. Comme Bob n'a jamais reçu le deuxième message intercepté d'Alice, il l'acceptera. Ce message représente une violation de la sécurité lorsqu'il encode une commande telle que "ouvrir la serrure".
Pour éviter ces types d'attaques, les actions programmées définissent un délai avant expiration maximal 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, elle ne pourra pas rejouer le message à l'étape 7 en raison d'un délai avant expiration expiré sur la transaction.
Les transactions temporelles augmentent la complexité et le nombre d'actions. Par conséquent, elles ne sont 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.
Abstraits du SDK
Les sections Transactions de lecture, Transactions d'écriture et Transactions d'appel offrent 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 abstraites par des fonctions de SDK qui les encapsulent dans une interaction. Toutefois, il est important de comprendre les actions IM pour fournir à l'ingénieur une bonne maîtrise des fonctionnalités de Matter, ainsi qu'un contrôle précis de l'implémentation du SDK.