El modelo de datos (DM) de un nodo no es relevante si no podemos realizar operaciones en él. El modelo de interacción (IM) define la relación de DM de un nodo con el DM de otros nodos: un lenguaje común para la comunicación entre los DM.
Los nodos interactúan entre sí de las siguientes maneras:
- Cómo leer y suscribirse a atributos y eventos
- Cómo escribir en atributos
- Cómo invocar comandos
Cada vez que un nodo establece una secuencia de comunicación encriptada con otro, constituyen una relación de interacción. Las interacciones pueden estar compuestas por una o más transacciones, y las transacciones están compuestas por una o más acciones, que se pueden entender como mensajes a 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 un evento a otro nodo, o su respuesta, la acción de informe de datos, 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 objetivo. 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 las 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 dirigir y enviar mensajes a varios dispositivos en la misma acción de forma 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 del grupo (Groupcast), Matter aprovecha los mensajes Multicast de IPv6, y todos los miembros del grupo tienen la misma dirección Multicast.
Rutas de acceso
Cada vez que queremos interactuar con un atributo, un evento o un comando, debemos especificar la ruta 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 grupos o operadores de comodín para abordar varios nodos o clústeres de forma simultánea, lo que agrega estas interacciones y, por lo tanto, disminuye 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 por el ser humano en la capacidad de respuesta del dispositivo. Este efecto hace que los múltiples dispositivos reaccionen a un comando con demoras visibles entre ellos. Esto suele denominarse "efecto palomitas de maíz".
Una ruta de acceso en Matter se puede ensamblar con una de las siguientes opciones:
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
Además, dentro de estos bloques de construcción de rutas, endpoint y cluster también pueden incluir operadores de comodines para seleccionar más de una instancia de nodo.
Con y sin límite de tiempo
Existen dos formas de realizar una transacción de escritura o invocación: con tiempo y sin tiempo. Las transacciones cronometradas establecen un tiempo de espera máximo para que se envíe la acción de escritura o invocación. El objetivo de este tiempo de espera es evitar un ataque de intercepción en la transacción. Es especialmente válido para dispositivos que restringen el acceso a recursos, como abridores y cerraduras de garajes.
Para comprender las transacciones con tiempo, es útil entender cómo pueden ocurrir los ataques de intercepción y por qué son importantes las transacciones con tiempo.
El ataque de intercepción
Un ataque de intercepción tiene el siguiente patrón:
- Alicia le envía a Roberto un mensaje inicial, como una acción de solicitud de escritura.
- Eva, un intermediario, intercepta el mensaje y evita que Roberto lo reciba, por ejemplo, a través de algún tipo de interferencia de radio.
- Al no recibir una respuesta de Roberto, Alicia envía un segundo mensaje.
- Eve vuelve a interceptarlo y evita que Roberto lo reciba.
- Eva envía el primer mensaje interceptado a Roberto, como si proviniera de Alicia.
- Roberto envía la respuesta a Alicia (y Eva).
- Eve retiene el segundo mensaje interceptado para volver a reproducirlo más adelante. Como Roberto nunca recibió el segundo mensaje interceptado original de Alicia, lo aceptará. Este mensaje representa una violación de seguridad cuando codifica un comando como “abrir cerradura”.
Para evitar estos tipos de ataques, las Acciones programadas establecen un tiempo de espera máximo de la transacción al comienzo de esta. Incluso si Eve logra ejecutar los primeros seis pasos del vector de ataque, no podrá volver a reproducir el mensaje en el paso 7 debido a que el tiempo de espera de la transacción caducó.
Las transacciones cronometradas 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 los recursos de seguridad y privacidad físicos o virtuales.
Abstracción de SDK
Las secciones Transacciones de lectura, Transacciones de escritura y Transacciones de invocación proporcionan 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 Acciones se abstraen con funciones del SDK que las encapsularán en una Interacción. Sin embargo, es importante comprender las Acciones de IM para proporcionarle al ingeniero una buena capacitación sobre las capacidades de Matter, así como un control detallado sobre la implementación del SDK.