El Modelo de datos (DM) de un nodo no es relevante si no podemos realizar operaciones en ellos. El Modelo de interacción (IM) define la relación de DM de un nodo con la de otros nodos: un lenguaje común para la comunicación entre DM.
Los nodos interactúan entre sí de la siguiente manera:
- Lectura y suscripción a atributos y eventos
- Cómo escribir en atributos
- Invocar comandos
Cada vez que un nodo establece una secuencia de comunicación encriptada con otro nodo, constituyen una relación de Interaction. Las interacciones pueden estar compuestas por una o más transacciones, y pueden estar compuestas por una o más acciones que se pueden interpretar como mensajes de nivel de IM entre nodos.
Se admiten varias acciones en las transacciones, como una acción de solicitud de lectura que solicita un atributo o evento de otro nodo o su respuesta, la acción de informe de datos, que transporta la información del servidor al cliente.
Iniciadores y objetivos
El nodo que inicia una transacción es el iniciador, mientras que el nodo que responde es el destino. Por lo general, el iniciador es un clúster de cliente y el destino es un clúster de servidor. Sin embargo, hay excepciones a este patrón, como las de Interacciones con suscripciones que se analizan más adelante en esta sección.
Grupos
Los nodos de Matter pueden pertenecer a un grupo. Un grupo de dispositivos es un mecanismo para asignar y enviar mensajes a varios dispositivos en la misma acción de manera simultánea. Todos los nodos de un grupo comparten el mismo ID del grupo, un número entero de 16 bits.
Para lograr una comunicación a nivel de grupo (Groupcast), Matter aprovecha los mensajes IPv6 de Multicast, y todos los miembros del grupo tienen la misma dirección Multicast.
Rutas de acceso
Siempre que queremos interactuar con un atributo, evento o comando, debemos especificar la ruta de acceso para esta interacción: la ubicación de un atributo, evento o comando en la jerarquía del modelo de datos de un nodo. La salvedad es que las rutas también pueden usar grupos o operadores de comodines para abordar varios nodos o clústeres a la vez, agregando estas interacciones y, por lo tanto, disminuyendo la cantidad de acciones.
Este mecanismo es importante para mejorar la capacidad de respuesta de las comunicaciones. Por ejemplo, cuando un usuario quiere apagar todas las luces, un asistente de voz puede establecer una sola interacción con varias luces dentro de un grupo en lugar de una secuencia de interacciones individuales. Si el iniciador crea interacciones individuales con cada luz, puede generar una latencia perceptible en los dispositivos. Este efecto hace que los varios dispositivos reaccionen a un comando con retrasos visibles entre ellos. Por lo general, se conoce como "efecto de palomitas de maíz".
Se puede ensamblar una ruta en Matter con una de las siguientes opciones:
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
Dentro de estos componentes básicos de la ruta de acceso, endpoint y cluster también pueden incluir operadores comodín para seleccionar más de una instancia de nodo.
Con sincronización y sin tiempo
Hay dos formas de realizar una transacción de escritura o invocación: Timed y Untimed. Las transacciones programadas establecen un tiempo de espera máximo para que se envíe la acción de escritura/invocación. El propósito de este tiempo de espera es evitar un ataque de interceptación en la transacción. Es especialmente útil para los dispositivos que puertas de acceso a elementos, como abridores de cocheras y cerraduras.
Para comprender las transacciones con tiempo, es útil comprender cómo pueden ocurrir los ataques de interceptación y por qué son importantes.
El ataque interceptado
Un ataque de interceptación tiene el siguiente patrón:
- Alice le envía un mensaje inicial a Bob, como una acción de escritura de solicitud.
- Eva, un intermediario, intercepta el mensaje y evita que Bob lo reciba, por ejemplo, a través de algún tipo de bloqueo de radio.
- Alicia no recibe un segundo mensaje de su respuesta.
- Eva vuelve a interceptarlo y evita que Roberto lo reciba.
- Eva envía el primer mensaje interceptado a Roberto, como si proviniera de Alice.
- Roberto envía la respuesta a Alicia (y Eva).
- Eva mantiene el segundo mensaje interceptado para volver a reproducirlo más tarde. Como Bob nunca recibió el segundo mensaje original interceptado de Alice, lo aceptará. Este mensaje representa una violación de la seguridad cuando se codifica un comando como “bloqueo abierto”.
Para evitar estos tipos de ataques, las Acciones con tiempo establecido establecen un tiempo de espera máximo de la Transacción al comienzo de la Transacción. Incluso si Eva logra ejecutar los primeros seis pasos del vector de ataque, no podrá volver a reproducir el mensaje en el paso 7 debido a que se agotó el tiempo de espera de la transacción.
Las transacciones programadas aumentan la complejidad y la cantidad de acciones. Por lo tanto, no se recomiendan para todas las transacciones, sino solo las operaciones críticas de los dispositivos que tienen control de los recursos de seguridad y privacidad físicos o virtuales.
Abstracciones de SDK
En las secciones Operaciones de lectura, Cómo invocar transacciones y Cómo invocar transacciones, se proporciona una descripción general de alto nivel de las acciones del modelo de interacción que realiza el SDK.
Por lo general, el desarrollador que crea un producto que usa el SDK de Matter no realiza llamadas para ejecutar acciones de forma directa; las funciones del SDK que las encapsulan en una interacción abstraen las acciones. Sin embargo, comprender las acciones de IM es importante proporcionar al ingeniero un buen dominio de las capacidades de Matter, así como un control preciso de la implementación del SDK.