Conceitos do modelo de interação

O modelo de dados (DM, na sigla em inglês) de um nó não será relevante se não for possível realizar operações nele. O modelo de interação (IM) define a relação do DM de um nó com o DM de outros nós: uma linguagem comum para comunicação entre DMs.

Os nós interagem entre si:

• Como ler e assinar atributos e eventos
• Como gravar em atributos
• Como invocar comandos

Sempre que um nó estabelece uma sequência de comunicação criptografada com outro nó, eles constituem uma relação de interação. As interações podem ser compostas de uma ou mais Transações, e as Transações são compostas de uma ou mais Ações, que podem ser entendidas como mensagens de nível de IM entre Nós.

Várias ações são compatíveis com as transações, como uma ação de solicitação de leitura, que solicita um atributo ou evento de outro nó, ou a resposta, a ação de dados do relatório, que transporta as informações de volta do servidor para o cliente.

Iniciadores e destinos

O nó que inicia uma transação é o Iniciador, enquanto o nó que responde é o Destino. Normalmente, o iniciador é um cluster de cliente, e o destino é um cluster de servidor. No entanto, há exceções a esse padrão, como nas interações de assinatura analisadas mais adiante nesta seção.

Grupos

Os nós em Matter podem pertencer a um grupo. Um grupo de dispositivos é um mecanismo para endereçar e enviar mensagens a vários dispositivos na mesma ação simultaneamente. Todos os nós em um grupo compartilham o mesmo ID de grupo, um número inteiro de 16 bits.

Para realizar a comunicação em grupo (Groupcast), o Matter usa mensagens Multicast IPv6, e todos os membros do grupo têm o mesmo endereço Multicast.

Caminhos

Sempre que quisermos interagir com um atributo, evento ou comando, precisamos especificar o caminho dessa interação: o local de um atributo, evento ou comando na hierarquia do modelo de dados de um nó. A ressalva é que os caminhos também podem usar grupos ou operadores curinga para abordar vários nós ou clusters simultaneamente, agregando essas interações e, assim, diminuindo o número de ações.

Esse mecanismo é importante para melhorar a capacidade de resposta das comunicações. Por exemplo, quando um usuário quer apagar todas as luzes, um assistente por voz pode estabelecer uma única interação com várias luzes em um grupo, em vez de uma sequência de interações individuais. Se o Iniciador criar interações individuais com cada luz, isso poderá gerar uma latência perceptível para humanos na capacidade de resposta do dispositivo. Esse efeito faz com que os vários dispositivos reajam a um comando com atrasos visíveis entre eles. Isso é conhecido como "efeito pipoca".

Um caminho em Matter pode ser montado usando uma das opções abaixo:

<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID>        <cluster> <attribute | event | command>

E, dentro desses elementos básicos de caminho, endpoint e cluster também podem incluir operadores curinga para selecionar mais de uma instância de nó.

Com e sem tempo limite

Há duas maneiras de realizar uma transação de gravação ou invocação: com tempo e sem tempo. As transações programadas estabelecem um tempo limite máximo para o envio da ação de gravação/invocação. O objetivo desse tempo limite é evitar um ataque de interceptação na transação. Isso é especialmente válido para dispositivos que controlam o acesso a recursos, como abridores de garagem e fechaduras.

Para entender as transações cronometradas, é útil entender como os ataques de interceptação podem acontecer e por que as transações cronometradas são importantes.

O ataque de interceptação

Um ataque de interceptação tem o seguinte padrão:

1. Alice envia a Bob uma mensagem inicial, como uma ação de solicitação de gravação.
2. Eve, um intermediário, intercepta a mensagem e impede que Bob a receba, por exemplo, por meio de algum tipo de interferência de rádio.
3. Alice, não recebendo uma resposta de Bob, envia uma segunda mensagem.
4. Eva intercepta novamente e impede que Bob a receba.
5. Eve envia a primeira mensagem interceptada para Bob, como se ela viesse de Alice.
6. Bob envia a resposta para Alice (e Eve).
7. Eva guarda a segunda mensagem interceptada para uma repetição posterior. Como Bob nunca recebeu a segunda mensagem original interceptada de Alice, ele vai aceitá-la. Essa mensagem representa uma violação de segurança quando codifica um comando como "abrir fechadura".

Para evitar esses tipos de ataques, as ações programadas definem um tempo limite máximo de transação no início da transação. Mesmo que Eve consiga executar as primeiras seis etapas do vetor de ataque, ela não poderá repetir a mensagem na etapa 7 devido a um tempo limite expirado na transação.

As transações programadas aumentam a complexidade e o número de ações. Portanto, elas não são recomendadas para todas as transações, mas apenas para as operações críticas em dispositivos que têm controle sobre recursos de segurança e privacidade físicos ou virtuais.

Abstrações do SDK

As seções Transações de leitura, Transações de gravação e Transações de invocação oferecem uma visão geral de alto nível das ações do modelo de interação realizadas pelo SDK.

O desenvolvedor que cria um produto que usa o SDK do Matter normalmente não faz chamadas para executar ações diretamente. As ações são abstraídas por funções do SDK que as encapsulam em uma interação. No entanto, entender as ações de IM é importante para que o engenheiro tenha uma boa proficiência nos recursos do Matter, além de um controle preciso sobre a implementação do SDK.