ry.cl. blog

 본 포스트에서는 CoAP(Constrained Application Protocol, RFC 2752)의 메시지 모델에서 지원하는 Request의 메소드와 Response의 코드 및 옵션에 대해 알아보았다. CoAP의 메시지 형식에 대한 내용은 아래 포스트에서 다룬 적이 있다. IoT protocol CoAP 메시지 구조(Message Format) 요약 정리 ∘ CoAP의 Request/Response 모델 CoAP는 HTTP의 Request/Response 모델과 유사하게 운영된다. 클라이언트는 서버로 CoAP Request를 보내고, 서버는 요청에 해당하는 응답을 클라이언트로 보내게 된다. 다만, CoAP는 HTTP와 달리 endpoint간에 TCP 연결을 필요로 하지 않는다. CoAP는 HTTP와 유사한 GET, PUT, POST, DELETE 메소드를 제공한다.  Request는 CoAP 헤더의 Code필드를 메소드 코드로 설정하고 Request 정보를 포함한다. Response는 헤더의 Code필드를 응답 코드로 하여 Response를 식별하도록 되어있다. 이는 HTTP에서 상태코드를 사용하는 것과 유사하다. Code 필드는 아래와 같이 Class와 Detail로 나눠진다. Class는 다음과 같은 카테고리로 구분된다.  0 Request 2 Response Success 3 Response Client Error, The Request contains bad syntax or cannot be fulfilled 4 Response Server Error The server failed to fulfill an apparently valid request ∘  Request/Response 전송 모델 CoAP에서 Request/Response 송수...

 CoAP(Constrained Application Protocol)는 제한된 환경에서 M2M(Machine To Machine) 요구사항을 충족하는 웹 프로토콜이며, 이런 특성으로 인해 IoT를 위한 프로토콜로 각광받고 있다고 한다. 본 포스트에서는 이러한 CoAP의 메시지 구조에 대해 알아봤으며, 앞으로 CoAP에 관한 더 많은 포스트를 게재할 예정이다. CoAP는 RFC 7252에 정의 되어있다. CoAP (Constrained Application Protocol) CoAP의 상호 작용 모델은 HTTP의 클라이언트/서버 모델과 유사하다.  그림 1. CoAP의 메시지는 각 EndPoint간 UDP를 통해 전송된다. 그림 2. CoAP Message Format 그림 3. CoAP Message Format CoAP의 메시지 형식은 위 그림과 같다.  - Var CoAP 버전을 의미한다. 값은 0b01이다. - T (Type) 메시지의 형식을 나타낸다. Confirmable(CON): 0 , ack를 요구하는 메시지 Non-confirmable(NON): 1 , ack를 요구하지 않는 메시지 Acknowledgement(ACK): 2 , CON 메시지에 대한 응답 메시지 Rest(RST): 3 , 메시지가 수신되었으나 올바르게 처리하기 위한 내용이 누락되었음을 나타내는 메시지 메시지의 타입은 아래와 같은 형태의 메시지에 사용된다. Empty 메시지는 일반적인 경우 CON형식은 사용되지 않으나...