[Matter] Interaction Model 개념
https://developers.home.google.com/matter/primer/interaction-model?hl=en
상호작용 모델 개념 | Matter | Google Home
법적 사안 상호작용 모델, 시작자, 대상, 그룹, 경로와 같은 관련 개념에 대해 알아봅니다.
developers.home.google.com
Interaction Model이란 노드간에 Data Model의 관계를 나타낸다. 즉 다시 말하면 노드의 Data Model간의 통신 언어라고 할 수 있다.
노드는 다음과 같이 노드간에 통신을 한다
- Attribute와 Event를 Reading 하고 Subscripbing 한다
- Attribute를 writing한다
- Command를 호출한다
노드가 다른노드와 암호와된 통신을 할 때, Interation이라는 것을 만들어 낸다.
이 Interaction은 하나 이상의 Transaction으로 이루어져 있다.
Transaction은 하나이상의 Action으로 이루어져 있다.
그리고 Action은 노드간의 통신에 사용되는 Interation Model Message로 생각 할 수 있다.
트랜잭션은 여러가지 액션을 지원한다. 예를들어 Read Request액션으로 다른노드의 Attribute나 Event를 읽어 올 수 있고, 또는 response를 날려 클라이언트에게 데이터를 전달 해 줄 수 있다.
Initiator와 Target
노드는 Initiator라는것을 통해 Transaction을 초기화 한다. response의 대상이 되는 노드를 Target이라고 한다.
일반적으로 Initiator는 보통 클라이언트의 Cluster이며, 타겟은 서버의 Cluster이다.
물론 당연히 예외가 있다. Subscription Interaction의 경우 양상이 조금 다르다. 아래 내용에서 설명하겠다.
Groups
매터의 노드는 Group으로 묶일 수 있다. 디바이스의 Group은 여러개의 디바이스가 하나의 Action을 동시에 처리하는 단위이다. 하나의 그룹에 있는 모든 노드들은 같은 Group ID를 가지며 이 아이디는 16bit 정수이다.
Group수준의 통신을 구현하기 위해(Groupcast), 매터는 IPv6 멀티캐스트 메시지를 활용하며, 모든 그룹 구성원은 동일한 멀티캐스트 주소를 갖는다.
Path
통신을 하는데 있어서 당연히 통신을 할 대상의 주소값이 필요하다. 매터에서는 이를 Path라고 부른다.
The location of an Attribute, Event or Command in the Data Model Hierarchy of a Node
노드 계층에 속성, 이벤트, 커맨드의 위치라는 뜻
Path는 Group단위의 주소 또는 Wildcard Operator가 존재한다. 이는 여러개의 노드 또는 클러스터를 동시에 다룰 수 있고, 여러개의 interation을 모아서 action의 수를 줄여준다.
이러한 메커니즘이 중요한 이유는, 이 메커니즘이 노드간의 통신의 response를 줄여주기 때문이다.
예를들어 한 유저가 모든 전구를 끄고 싶다면, 보이스 어시스턴트가 하나의 interaction을 여러개의 전구를 대상으로 생성한다. 이는 전구 하나하나 개별로 interaction을 설정하는거에 비해 훨씬 비용이 적게든다. 만약 전구 개별로 interation을 설정할 경우 눈에 띄는 delay가 보일 것이다. 이런 현상을 팝콘 현상(popcorn effect)라고 한다
매터의 Path의 예시는 다음과 같다.
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
Timed와 Untimed
Transcation을 만드는 방법은 두가지 이다. Timed와 Untimed. 두개의 차이는 timeout이 있냐 없냐의 차이이다.
여기서 timeout이 있는것은 Timed Transaction이다. Timed Transaction은 Intercept Attack을 예방하는 목적이 있다.
Intercept Attack의 예시는 다음과 같다
- Alice가 Bob에게 write Request Action으로 메세지를 보낸다
- Eve라는 사람에 중간이 메세지를 가로채고 라디오 전파 같은걸로 Bob이 메세지를 수신하는걸 방해한다
- Alice는 Bob이 답장이 없자 두번째 메세지를 보낸다
- Eve가 두번쨰 메세지까지 가로챈다.
- Eve가 처음에 가로챈 메세지를 Bob에 보낸다
- Bob은 이것에 답장한다. Alice 그리고 Eve까지
- Eve는 두번째 메세지를 가지고 있다가 다시 Bob에게 보낸다. Bob은 두번째 메세지를 받아본적이 없기 때문에 아무 문제없다 생각하고 다시 답장한다.
(구글놈들이 설명을 드럽게 못한다. 걍 중간에 메세지 가로채고 있다 이런문제로 넘어가시길..)
이러한 상황은 보안문제를 일으킨다. 이를 막기위해 Timed Transaction은 시작즈음에 timeout을 설정한다.
위 상황에서 어찌 저찌 Eve가 첫번째 메세지로 밥을 속이는것을 성공했더라도, timeout이 있기에 두번째 메세지로 Bob을 속이는것은 타임아웃 때문에 실패할 것이다.
Timed Transaction은 Action의 복잡도와 숫자를 증가시킨다. 그러므로 권장되는 사항은 아니나 물리적인 동작을 가진 디바이스(가령 차고 문 열기 등등)나 보안문제가 중요한 디바이스에 사용하는것을 권장한다.
다음으로 Transaction의 종류에 대해 설명
Read Transaction
첫번째 usecase는 다른노드의 Attribute의 값을 읽어오는 Read Transaction이다. 예를들어 센서의 온도같은걸 읽어오는 예시가 있겠다. Read Transaction은 처음에 반드시 Read Request Action을 먼저 날려야 된다.
Read Request Action
Initiator에서 Target 방향으로 진행된다. 이 액션을 통해 Attribute와 Event를 요청할 수 있다.
이 액션은 0개에서 하나 이상의 리퀘스트를 날린다.
Report Data Action
Target에서 initiator 방향으로 진행된다. 타겟이 request를 받으면, Report Data Action을 모아서 initiaotr에 넘겨준다.
Report 데이터에는 다음과 같은 데이터가 담겨있다
- Attribute Reports : Attribute가 0개 이상 담겨있다
- Event Reports : Event가 0개 이상 담겨있다
- Suppress Response : flag이며 status response가 필요없는지 아닌지를 나타낸다
- Subscription ID : 만약 리포트가 subscription transaction에 해당되면, 이 액션은 반드시 subscription transaction을 구별할 수 있는 integer값을 담아야 한다
Status Response Action
Target -> Initiaotr -> Target 방향으로 진행된다. 이니시에이터가 요청된 데이터를 받으면 타겟에게 잘 받았다고 전달해주는 값이다. 만약 앞서 배운것처럼 요청된 데이터에 Suppress Response 플래그가 set 되어있다면, Status Response를 보내면 안된다.
Response Action은 단순히 리퀘스트가 성공했는지 실패했는지에 대한 status 데이터만 보낸다.
타겟이 response를 받거나 이니시에이터가 요청된 데이터를 받고 Suppress Response가 set된 경우 이 쿼리는 종료된다.
Read Restriction
한가지 기억해야 할 점은 Read Request Action과 Report Data Action은 unicast라는 점이다. 즉 이 리퀘스트의 Path는 Group을 담으면 안된다.
Status Response Action도 마찬가지로 unicast이며 groupcast의 response로 사용되면 안된다.
Subscribe Transaction
구독 Transaction. 이름에서만 봐도 알 수 있듯이 주기적으로 Attribute 또는 Event를 읽어올 수 있는 Transaction이다.
Subscription Interaction은 두 노드간에 relationship을 형성하고 타겟이 Report Data Action을 주기적으로 이니시에이터에 보내주게 된다.
여기서 이니시에이터를 Subscriber라고 하고 타겟을 Publisher라고 한다.