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 el de otros nodos: un lenguaje común para la comunicación entre DM.
Los nodos interactúan entre sí de las siguientes maneras:
- Cómo leer atributos y eventos y suscribirte a ellos
- Escribe en atributos
- Invocación de comandos
Cada vez que un nodo establece una secuencia de comunicación encriptada con otro nodo, constituye una relación de Interacción. Las interacciones pueden estar compuestas por una o más Transacciones, y estas se componen de una o más acciones que se pueden interpretar como mensajes a nivel de IM entre nodos.
Transacciones admiten varias acciones, como una acción de solicitud de lectura que solicita un atributo o evento de otro nodo, o su respuesta, la acción de datos de informe, que lleva 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 objetivo es un clúster de servidor. Sin embargo, hay excepciones a este patrón, como en el análisis de Interacciones de suscripción 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 direccionar 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 de grupo, un número entero de 16 bits.
Para lograr la comunicación a nivel de grupo (Groupcast), Matter aprovecha los mensajes IPv6 Multicast y todos los miembros del grupo tienen la misma dirección Multicast.
Rutas de acceso
Cuando queramos interactuar con un atributo, evento o comando, debemos especificar la ruta de acceso para esta interacción: la ubicación de un atributo, un evento o un comando en la jerarquía del modelo de datos de un nodo. La salvedad es que las rutas de acceso también pueden usar operadores de comodín o grupos 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 desea 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 latencia perceptible humana en la capacidad de respuesta del dispositivo. Este efecto hace que los varios dispositivos reaccionen a un comando con retrasos visibles entre ellos. Esto suele denominarse "efecto de palomitas de maíz".
Se puede crear una ruta de acceso en Matter mediante 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 comodines para seleccionar más de una instancia de nodo.
Con y sin tiempo
Hay dos maneras de realizar una transacción de invocación o escritura: con tiempo y sin tiempo. Las transacciones temporizadas establecen un tiempo de espera máximo para que se envíe la acción de escritura o invocación. El propósito de este tiempo de espera es evitar un ataque de intercepción en la transacción. Es especialmente válida para los dispositivos que restringen el acceso a recursos, como cerraduras y aperturas de cocheras.
Para comprender las transacciones temporizadas, es útil comprender cómo pueden ocurrir los ataques de intercepción y por qué son importantes.
El ataque de la intercepción
Un ataque de intercepción tiene el siguiente patrón:
- Alicia le envía un mensaje inicial a Roberto, como una acción de solicitud de escritura.
- Eva, un intermediario, intercepta el mensaje y evita que Bob lo reciba, por ejemplo, a través de algún tipo de improvisación de la radio.
- Alicia, que no recibe una respuesta de Roberto, envía un segundo mensaje.
- Eva intercepta de nuevo y evita que Bob lo reciba.
- Eva envía el primer mensaje interceptado a Bob, como si proviniera de Alice.
- Roberto les envía la respuesta a Alice (y a Eva).
- Eva retiene el segundo mensaje interceptado para volver a reproducirlo más tarde. Como Bob nunca recibió el segundo mensaje interceptado original de Alice, lo aceptará. Este mensaje representa una violación de la seguridad cuando el mensaje codifica un comando como "open lock".
Para evitar estos tipos de ataques, las acciones programadas establecen un tiempo de espera máximo para 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 venció el tiempo de espera de la transacción.
que aumentan la complejidad y la cantidad de acciones. Por lo tanto, no se recomiendan para cada transacción, sino solo para las operaciones críticas en dispositivos que tienen control sobre la seguridad física o virtual y los activos de privacidad.
Abstracciones de SDK
En las secciones Transacciones de lectura, Escritura de transacciones y Invocación de 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 directamente; las funciones del SDK abstraen las acciones que las encapsulan en una interacción. Sin embargo, comprender las acciones de IM es importante para proporcionarle al ingeniero un buen dominio de las capacidades de Matter, así como un control detallado de la implementación del SDK.