El modelo de datos (DM) de un nodo no es relevante si no podemos realizar operaciones en él. El Interaction Model (IM) define la relación de DM de un nodo con la DM de otros nodos: un lenguaje común para la comunicación entre las DM.
Los nodos interactúan entre sí de las siguientes maneras:
- Lectura y suscripción a atributos y eventos
- Escritura de atributos
- Invocación de comandos
Cuando un nodo establece una secuencia de comunicación encriptada con otro nodo, se establece 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 MI entre nodos.
En las transacciones se admiten varias acciones, como la acción de solicitud de lectura, que solicita un atributo o evento de otro nodo, o su respuesta, y la acción de datos de informe, que lleva la información de vuelta del servidor al cliente.
Iniciadores y destinos
El nodo que inicia una transacción es el Iniciador, mientras que el nodo que responde es el Objetivo. Normalmente, el iniciador es un clúster de clientes y el destino es un clúster de servidores. 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 en 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 forma simultánea. Todos los nodos de un grupo comparten el mismo ID de grupo , un 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
Siempre que queramos interactuar con un atributo, un evento o un 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 advertencia es que las rutas 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 usuario 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 se conoce como "efecto palomitas de maíz".
Se puede ensamblar una ruta de acceso en Matter con una de las siguientes opciones:
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
Y dentro de estos bloques de construcción de Path, endpoint y cluster también pueden incluir operadores comodín para seleccionar más de una instancia de Node.
Con y sin límite de tiempo
Existen dos formas de realizar una transacción de escritura o invocación: cronometrada y sin cronometrar. Las transacciones cronometradas 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álido para los dispositivos que controlan el acceso a los recursos, como los abridores de puertas de garaje y las cerraduras.
Para comprender las transacciones temporizadas, es útil entender cómo pueden ocurrir los ataques de interceptación y por qué son importantes las transacciones temporizadas.
El ataque de intercepción
Un ataque de interceptación tiene el siguiente patrón:
- Alicia le envía a Bob un mensaje inicial, como una acción de solicitud de escritura.
- Eve, una agente intermediaria, intercepta el mensaje e impide que Bob lo reciba, por ejemplo, mediante algún tipo de interferencia de radio.
- Alice, al no recibir una respuesta de Bob, envía un segundo mensaje.
- Eve vuelve a interceptar el mensaje y evita que Bob lo reciba.
- Eve le envía el primer mensaje interceptado a Bob, como si proviniera de Alice.
- Bob envía la respuesta a Alicia (y a Eva).
- Eve retiene el segundo mensaje interceptado para reproducirlo más tarde. Como Roberto nunca recibió el segundo mensaje interceptado original de Alicia, lo aceptará. Este mensaje representa una vulneración de la seguridad cuando codifica un comando como "abrir cerradura".
Para prevenir este tipo de ataques, las Acciones Temporizadas establecen un tiempo de espera máximo para la transacción al inicio de la misma. Incluso si Eve logra ejecutar los primeros seis pasos del vector de ataque, no podrá reproducir el mensaje en el paso 7 debido a que ha expirado el tiempo de espera de la transacción.
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 activos de seguridad y privacidad físicos o virtuales.
Abstracciones del SDK
En las secciones Read Transactions, Write Transactions y Invoke Transactions, se proporciona una descripción general de alto nivel de las acciones del modelo de interacción que realiza el SDK.
Normalmente, el desarrollador que crea un producto que utiliza el SDK Matter no realiza llamadas para ejecutar acciones directamente; las acciones se abstraen mediante funciones del SDK que las encapsulan en una interacción. Sin embargo, comprender las acciones de IM es importante para que el ingeniero tenga un buen dominio de las capacidades de Matter, así como un control preciso sobre la implementación del SDK.