Applications Use Transport
UDP based
- Short messages, simple request/response trasactions
- Light server touch, ARQ suffices
- Real Time Protocol (RTP): Low delays, ARJ, short messages, weak client/server relationship
TCP based
- Larger contents, longer, more complex sessions
- Reliaibility, Packaging and presentation important (as it is bytestream)
- HTTP: Strong client/server relationship, exchange messages.
Internet of Things - Why different?
- Scale: 기기의 숫자
- No limits on addresses and connections
- Limit messages to avoid network swamp - 숫자가 너무 많아서 메세지 크기를 줄여야함
- Power:
- Minimal powers; solar, batteries, RF
- Reduce/turnoff transmission power
- Do the smart things somewhere (which consums powers alot) - 즉 IoT는 수집 모니터링 과 같은 역할만 수행하고 분석은 다른 컴퓨터에서 하는것
- Minimal powers; solar, batteries, RF
- Networking: 저전력, 원격 위치, 넓게 분포
- Limit transmission needs - 메세지 보내는것도 에너지/트래픽이 요구됨
- Reduce bandwidth/distance/targets - 스스로 제한을 걸어서 통신횟수를 줄이던지;
- Get/give helps from the neighbours - 주위와 연계해서 전체적인 통신횟수를 줄이던지; 대신 이러면 항상 깨어 있어야함
- Limit transmission needs - 메세지 보내는것도 에너지/트래픽이 요구됨
- Timeliness: 빠른 지시와 반응이 필요 할 수 있음
- 다음과 같은 사항을 고려하여 디자인 한다
- Exceptions vs Regular Reports - 언제 리포트 하는지
- Transmitter vs Receiver Req - 송수신기 필요성
- Short msg, prioritised msg - 메세지
- 다음과 같은 사항을 고려하여 디자인 한다
- Reliability: 조그맣기에 어렵다
- 필요할떄만 의존성 사용, 최대한 가볍게 (ARQ push/pull 이라던지)
Design - PubSub
- 데이터와 상태의 “announcement” 는 “consumption”과 분리되어 있다.
- 모든 종류, 숫자의 소비자들이 subscribe 할수 있어야 하고
- 모든 종류, 숫자의 소스들이 publish 될 수 있어야 한다
- Avoid “connection” - 5번과 연계됨
- 위의 사항들을 만족하기 위해 “broker” (server) is needed
- 가볍고, 빠르고, 유연하며, open된 브로커 (당연히 웹서버는 이에 해당안됨)
- 각각의 기기들은 브로커에게 퍼블리시 할 뿐이고, 브로커가 소비자들의 요구를 감당한다. 이로 인해 각각의 기기들은 위의 조건들을 만족할 수 있는것.
MQTT (브로커)
Messeage Queuing Telemetry Transport: 많은 IOT기기들에 최적화된 가벼운 메세징 프로토콜. 낮은 전력 낮은 대역폭 낮은 성능의 환경에서도 사용이 가능하다.
- TCP와 높은 버전의 UDP 등등 여러 프로토콜에 의해 사용된다.
통신 과정
- Publisher (센서 장치)가 데이터를 Topic을 정해서 브로커에게 전달.
- 이 Topic을 sub 하는 subscriber (출력, 처리 장치) 가 브로커에게서 데이터를 받아온다
- 만약 해당 토픽을 구독하고 있지 않으면, 데이터는 받지 못한다.
특징
- Pub - any vaule type to a specific (key).
- Sub - subs to particual topic (which may not exist now, but in the future), or to a fitered set of topics (such as Pizza, instead of Hawaiian pizza)
- Broker -
- $sys/# - special topic
- Holds info about the broker itself
- 로드, 대역폭, 저장, 클라이언트 등등
- 하지만 브로커간에 정형화된 필드가 존재 하지 않음 (각 브로커마다 다름)
- 또한 resolution 이 다름 (즉 각 브로커마다 메세지 퍼블리시 텀이 다름)
- TCP 와 UDP (버전에 따라) 모두 사용가능하다
- 매우 비트단위인데, 압축된 메세지, 그리고 퍼블리셔와 네트워크의 부담을 줄이기 위해서이다.
메세지
- 16 Messages Types
- Connect and disconnect and ACK
- 채널과 서버 상태 확립, 그리고 스스로를 identify (lighweight security).
- Ping req and response - Server level; 어플리케이션 계층 (not ICMP - network layer)
- Pub, sub, unsub: 퍼블리시의 경우 양쪽 다 쓰임 소스 → 서버, 서버 → 구독자
- 다양한 Quality of Service
- Connect and disconnect and ACK
- 16 Messages Types
Minimalism (main MQTT rule)
- 서버는 최대한 적은 amount of state를 유지하기를 원한다.
- 구독자: “잠시동안 불가능” “더이상 흥미없음” 등등?
- 서버는 메세지를 queue 하지 않음 - mostly
- 구독자들에게 메세지가 배포되면, 그 메세지는 삭제된다
- 구독자가 없는 메세지 또한 삭제된다
- 서버가 데이터베이스를 청소할 수 있는 기회를 제공한다 (최대한 가볍게 유지)
- 서버는 최대한 적은 amount of state를 유지하기를 원한다.
QoS
어플리케이션 레벨에서 가지고 있는데 이는
- 몇 구독자의 경우에 “확정 - sure” 이 필요하고
- 모든 구독자는 어느때나 참여 할 수 있어야 하고
- 전원, 게이트, 버퍼 여유분 등등 여러 사항을 고려할 수 있어야 하기 때문
다음과 같이 세가지 레벨을 가지고 있다.
0: 메세지를 푸시하고 바로 삭제해 버림 (Fire and Forget)
1: 전달을 보장한다. 따라서 확인 절차가 필요하다 (At least once)
2: 전달을 보장하고, 4단계의 핸드셰이크를 이용한다 (Exactly once)
다음과 같은 상황도 가능하다.
Last Known Good
- 드물게 보고하는 센서들
- 새 구독자에게 뭘 줘야함 (드물게 pub 되서 마지막이 어느 상태인지 알려줘야지)
- Retain: 메세지를 삭제할지 유지할지 정하는 플래그
- 서버에 저장되며, 리붓되어도 존재한다. 구독자에게서 처음으로 요청 받을때 보내진다.
Last Will and Testament
어느 토픽이던 소스는 초기 메세지를 배포할수 있다 - retained 메세지, 바로 보내지는 않는다
만약 서버가
배포된 메세지를 keepalive 구간 후에 받지 못하거나
TCP 연결이 MQTT 종료 메세지 없이 끊기거나
한다면 연결을 잃었으며 Soruce는 실패했다고 판단한다.
이후 각 구독자에게 알린다 (현재 서비스 불가능 등등)
Clean Session
- 연결시에 플래그 됨
- Clean: Pretend Ima new one
- Not clean: Persistent Session - Ask server to remember you.
- Plain for the server:
- 너의 모든 구독된 토픽을 저장한다
- 모든 메세지들을 저장한다 (QoS 1 and 2)
- 재연결 되었을때 놓친 모든 메세지를 전달한다.
MQTT의 경우 어느정도의 보안이 존재하나 IoT의 경우 없다고 봐도 무방하다
- 아이디 비번
- 페이로드 시그네쳐, 무결성 검사
- 암호화된 연결 등등
