[study] MOM and RESTful

[study] MOM and RESTful

---

네트워크를 통해 서비스를 제공하는 방법

 

1. Message-orientated Middleware(MOM)

• Communication between two devices takes places using distributed message queues
• Some devices produce data to be added to a queue while others consume data stored in a queue
• Require a broker or middleman to be the central service
• MQTT (TCP/IP)

---

2. RESRful model (Representational State Transfer)

• A server owns the state of a resource, but the state is not transferred in a message to the server from the client
• HTTP methods such as GET, PUT, POST, and DELETE to place requests upon a resource's Universal Resource Identifier(URI)
• No broker or middle agent is needed 
• Client - server architectures
• Clients initiate access to resources through sysnchronous request-response patterns.

---

3. MOM vs. RESTful

MOM : TCP 기반, subscribe, publish, 많은 client들이 publisher, subscribers 둘 다 될 수 있다. 중간자 O

 

RESTful: UDP 기반, HTTP위에서 동작, client to server 인데 UDP임. NO 중간자

---

4. MQTT

• Address problems in independent and non-concurrent distributed systems
• Help nodes of distributed systems to securely communicate
• QOS제공
• 다양한 형식 data 지원 (Be data agnostic)
• simple, lightweight messaging protocol,
• designed for constrained devices, low-bandwidth, high-latency or unreliable networks. and to minimize network bandwidth and device resource requirements.
• The clients are not aware of any physical identifiers such as the IP address or port

- Filters

• Subject filtering : 구독 안한 거 필터링. 중개인은 rebroadcasting나 ignoring 책임이 있다.
• Content filtering : 암호화되지 않은 데이터는 브로커에 관리될 수 있다.
• Type filtering : A client listening to a subcribed data stream can apply their own filters as well

- Topology -> broker를 중앙에 둔 star 형태이다. 

 

- Decupling publishers from consumers ( 발행자와 소비자를 분리시킴)

• 물리적 측면에서 (IP주소 같은) publisher와 consuber는 직접적으로 확인할 필요가 없다. 
• Very useful in IoT deployments as the physical identity may be unknown or ubiquitous
• 한 클라이언트에 의해 발행된 메시지는 구독자로 인해 몇 번이나 읽히거나 응답될 수 있다.
• Cloud-managed MQTT brokers typically can ingest millions of messages per hour and support tens of thousands of publishers

- Data format agnostic (형태 자유)

 Maximum packet size : 256MB(document)

그래도 클라우드 서비스에선 KB로 제한한다. 

IBM Wastson : 128 KB, Google 256 KB (commercial)

 

- Shared Subscription in MQTT5 => grouping 개념. $share/GROUPID/TOPIC

 

-QoS levels 

• QoS-0 ( 보장 x , 되면 되고 안되면 안 되고)
• QoS-1 (최소 한 번은 ok (ACK))
• QoS-2 (100% 신뢰 보장)

- Topic and wildcard

• + single level wildcard
• # multi level wildcard
• $ special topics

- Versions and features 

최초 릴리즈 - 1999

MQTT 3.1 - 2010

MQTT 5 - 2019

---

5. Constrained Application Protocol

 CoAP

• Providing a similar and easy structure of resource addressing familiar to anyone with experience using the web
• Reducing resources and bandwidth demands than the web

HTTP는 TCP/IP인데 / CoAP는 UDP이고 HTTP보다 더 저전력, 긴 배터리 수명을 가진다. (메시지 교환 횟수 줄임)

 

- 특징

HTTP 유사

보안 DTLS( for UDP)

Asynchronous message exchanges

가벼움

URI 지원 

 

-구조

Request / response layer :  piggybacked(복합운송)

Transactional layer : CON(ACK요구, ack안 오면 계속 data 보냄), NON(ACK x), ACK(CON에 대한 ack 보내면서 data 같이 전송), RST( connection이 사라졌을 때 반송)

 

CoAP Stack

 

CoAP

UDP

IPv6

6LoWPAN -배터리 절약

IEEE 802.15.4 - ZigBee

Bluetooth

 

- URI of CoAP

coap ://host[:port]/[path][?query]

 

---

6. MQTT vs CoAP

• MQTT 는 MOM pub/sub model (broker o) TCP, broadcasting - indirect (wildcard사용), 3level QoS
• CoAP 는 RESTful server/client model (borker x) UDP, broadcasting o , QoS는 CON messages 보장