IoT Protocol CoAP 메시지 요청/응답 모델 내용 정리

 본 포스트에서는 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 송수신 모델은 다음 3가지로 구분될 수 있다.

1. Piggybacked

클라이언트의 Request에 대해 서버는 바로 Response를 반환한다.


2. Separate

서버는 Request를 받은 후 ACK를 보내고, 기 요청된 데이터가 준비되면 클라이언트로 메시지를 전송한다.


3. Non-confirmable

클라이언트에서 Non-confirmable 메시지로 Request를 보낼 경우, Server는 새로운 Non-confirm 메시지를 사용해 Response를 보낸다.


[Note] Request/Response의 매칭은 Piggybacked response의 경우 request의 Message ID와 Token이 동일해야 하며, separate response의 경우 해당 Request과 동일한 Token을 사용해야 한다. 




∘ Request Method

GET

Code는 0.01 이다.

Request URI로 구분되는 리소스에 메시지내의 representation에 해당하는 정보를 검색/요청한다.

Request에 Accept 옵션이 있을 경우, 이 옵션에서 지정한 콘텐츠 형식으로 Response의 Payload를 만들어야 한다.

만약 Request에 ETag 옵션이 포함되어 있을 경우, GET 메서드는 ETag의 유효성을 검사하고, 유효성이 실패한 경우에만 정보표현이 전송되도록 요청한다. 

요청에 성공할 경우 2.05(Content)나 2.03(Valid)가 Response Code에 들어 있어야 한다. (SHOULD)

[Note] representation은 CoAP 메시지의 payload에 들어있는 내용을 의미한다. 예를 들어 위 전송 모델 이미지내의 "temperature"로 문자열로 표현된 데이터를 representation이라 한다.


POST

Code는 0.02며 POST 메서드는 Request에 포함된 representation을 처리하도록 요청한다. 

서버에서 POST 메서드에 의해 리소스가 생성된 경우, Response에 2.01(Created) Response Code와 새 리소스의 URI가 포함된 Location-Path 와/혹은 Location-Query Option이 포함되어야 한다. (SHOULD)

서버에서 POST 처리가 성공했으나 새로운 리소스가 만들어지지 않은 겨우 Response에는 2.04(Changed) Response Code가 포함되어야 한다. (SHOULD)

만약 POST에 의해 리소스가 제거되었을 경우, Response에는 2.02(Deleted) Response Code가 포함되어야 한다.


PUT

Code는 0.03이며 PUT 메서드는 request URI로 식별된 리소스를 메시지내에 전달되는 representation을 이용하여 업데이트 하거나 생성하도록 요청한다. 

Representation 형식은 Content-Format 옵션이 있다면 이 형식에 따른다.

Request URI에 리소스가 존재한다면, 동봉된 representation은 해당 리소스의 수정버전으로 인식되고, 2.04(Change) Response Code를 응답한다. 만약 리소스가 존재하지 않는다면, 2.01(Created) Response Code를 응답한다. 만약, 업데이트 하거나 새로 생성하지 못한다면 error response code를 응답한다. (SHOULD)

PUT 메소드에는 If-Match, IF-None-Match 옵션을 포함할 수 있다. 


DELETE

Code는 0.04이고, Request URI로 식별되는 리소스를 제거하는 요청을 한다.

제거 성공이나 해당 리소스가 없는 경우, 2.02(Deleted) Response Code를 응답한다.




∘ Response Code

Success 2.xx

2.01 Created - POST, PUT 요청의 응답. Location-Path/Location-Query 옵션이 포함될 수 있다. Not Cacheable

2.02 Deleted - DELETE, POST 요청의 응답. Not Cacheable

2.03 Valid - ETag 옵션으로 식별된 entity-tag로 식별된 응답이 유효한지 나타내기 위해 사용된다. 응답에 ETag 옵션이 포함돼야 하며, payload는 포함되어서는 안 된다. 

2.04 Changed - POST, PUT 요청의 응답. Not Cacheable

2.05 Content - HTTP 200 “OK”와 같으며 GET 요청의 응답으로만 사용된다. 요청된 데이터가 들어있는 Payload를 함께 반환한다. Cacheable 


Client Error 4.xx

4.00 Bad Request - HTTP 400 “Bad Request”와 같다. 

4.01 Unauthorized - 클라이언트가 요청 작업을 수행할 권한이 없음을 의미한다. 

4.02 Bad Option - 서버가 요청을 이해하지 못함을 의미한다. 

4.03 Forbidden - HTTP 403 “Forbidden”과 같아. 

4.04 Not Found - HTTP 404 “Not Found”와 같다. 

4.05 Method Not Allowed - HTTP 405 “Method Not Allowed와 유사하다.

4.06 Not Acceptable - HTTP 406 “Not Acceptable”과 같지만, response entity가 없다. 

4.12 Precondition Failed - HTTP 412 “Precondition Failed” 

4.13 Request Entity Too Large - HTTP 413 “Request Entity Too Large”와 같다. 응답에는 Size1 옵션을 포함해 처리가능한 최대 크기를 알려준다. (SHOULD)

4.15 Unsupported Content-Format - HTTP 415 “Unsupported Media type”과 같다. 


Server Error 5.xx

5.00 Internal Server Error - HTTP 500 “Internal Server Error”와 같다. 

5.01 Not Implemented - HTTP 501 “Not Implemented”와 같다.

5.02 Bad Gateway - HTTP 502 “Bad Gateway”와 같다. 

5.03 Service Unavailable - HTTP 503 “Service Unavailable”과 같으나, HTTP 헤더 필드의 “Retry-After” 대신 CoAP에서는 MAX-Age 옵션이 사용된다.

5.04 Gateway Timeout - HTTP 504 “Gateway Timeout”과 같다. 

5.05 Proxying Not Supported - 서버가 Proxy-Uri 옵션이나 Proxy-Scheme을 사용에 지정된 URI에 대해 forward-proxy 역할을 수행할 수 없거나 실행하지 않음을 의미한다. 




∘ Request/Response 옵션

CoAP의 옵션은 아래 표와 같으며, Option Number로 구분된다. 

Uri-Host, Uri-Port, Uri-Path, Uri-Query

Uri-Host, Uri-Port, Uri-Path, Uri-Query는 CoAP서버에 요청 대상 리소스를 지정하는데 사용된다. 

Uri-Host - 요청중인 리소스의 인터넷 호스트를 지정한다. 

Uri-Port - port 번호를 지정한다. 

Uri-Path - 리소스의 절대 경로를 지정한다. 

Uri-Query - 리소스를 매개 변수화 하는 하나의 인수를 지정한다. 


Proxy-Uri and Proxy-Scheme

Proxy-Uri는 forward-proxy에 대한 request를 만드는데 사용된다.

Forward-proxy는 request를 전달하거나 프록시 내부의 유효한 캐시에서 서비스하고 response를 반환하도록 요청된다. Option 값은 Absolute-Uri이다. 

Forward-proxy 동작은 예를 들어, 클라이언트가 example.com 에 연결하려고 하면 사용자 클라이언트가 직접 연결하는 것이 아니라 포워드 프록시 서버가 요청을 받아서 example.com 에 연결하여 그 결과를 클라이언트에 전달(forward) 해 준다. Forward-proxy는 대개 caching 기능이 있으므로 자주 사용되는 컨텐츠라면 월등한 성능 향상을 가져올 수 있으며 정해진 사이트만 연결하게 설정하는 등 웹 사용 환경을 제한할 수 있으므로 기업 환경 등에서 많이 사용한다.

Proxy-Uri를 받은 endpoint가 forward-proxy 역할을 수행하지 못할 경우 5.05 (Proxying Not Support) Response code를 응답해야 한다. (MUST)

Proxy-Uri는 Uri-Host,Uri-Port,Uri-Path, Uri-Query옵션보다 우선시되어야 한다.(MUST)

많은 프록시 클라이언트를 단수화 하기 위한 특별한 경우 Absolute-Uri는 Uri-* 옵션에서 구성할 수 있다.

Proxy-Scheme이 있는 경우 Absolute-Uri는 Uri-* 옵션들로 구성된 결과 URI에서, 초기 체계까지, 그러나 포함하지 않고, 다음 콜론이 Proxy-Scheme 내용으로 대체된다. 


Content-Format

Payload에 있는 메시지의 표현 형식을 지정한다. 표현 형식은 아래표의 숫자 ID를 사용한다.  


Accept

Accept은 클라이언트가 받아들일 수 있는 Content-Format을 알려주는데 사용한다. 포맷은 위 표의 숫자 ID를 사용하여 전달한다.

만약 Accept 옵션이 없는 경우 디폴트 값으로 인식되고 서버는 가능 하면 Content-format을 표시해 응답한다.  

만약 서버에서 선호된 Content-Format을 사용하여 응답메시지를 보낼 수 없으면, 4.06 (Not Acceptable) Response Code를 반환해야 한다. (MUST)


Max-Age

Max-Age는 Response가 최대로 캐시될 수 있는 시간을 지정한다. 만약 Max-Age 옵션이 없다면, 디폴트 값으로 60초다.


ETag

HTTP의 ETag 참조 https://en.wikipedia.org/wiki/HTTP_ETag

entity-tag는 오랜 시간후의 동일한 리소스의 표현을 구별하기 위해 resource-local 식별자로 사용하기 위한 것이다. 서버에의 해 생성되며 버전, 체크섬, 해시, 시간 등을 포함한 다양한 방식으로 생성될 수 있다. 


Location-Path and Location-Query

Location-Path와 Location-Query 옵션 둘은 절대 경로, 쿼리 문자열 또는 둘 다로 구성된 상대 URI를 나타낸다. 

이 조합은 2.01 (Created) Response에 포함되어 POST 요청의 결과로 리소스가 생성된 위치를 알려주는데 사용된다. 위치는 요청 URI의 기준으로 결정된다. 


Conditional Request Options (IF-Match, IF-None-Match)

이 옵션을 사용하면 서버는 특정 요건을 충족한 경우에만 클라이언트의 요청을 수행한다. 

조건을 만족하지 않으면, 요청을 수행해지 않아야 하며, 서버는 4.12 (Precondition Failed) Response Code를 반환해야 한다.

IF-Match/IF-None-Match 옵션은 일반적으로 여러 클라이언트가 동일한 리소스에서 병렬로 작동할 때 실수로 덮어쓰지 않도록 보호기이 위한 수단으로 사용되며, PUT Request에서 IF-Match는 리소스 업데이트에 IF-None-Match는 생성 요청에 유용한다. 

IF-Match 옵션의 값은 ETag거나 빈 문자열이다. ETag인 일치하는 representation ETag인 경우를 의미하고, 빈 문자열인 경우 대상 리소스의 representation이 존재하는가에 전제 조건을 부여한다. 

IF-None-Match 옵션의 값은 비어 있으며, 만약 리소스가 비어 있으면 조건을 충족하지 않는 것을 의미한다. 


Size1

Size1 옵션은 Request를 보낸 클라이언트가 처리할 수 있는 리소스의 크기 정보를 서버로 전달할 때 사용한다. 


댓글

댓글 쓰기

이 블로그의 인기 게시물

쉽게 설명한 파티클 필터(particle filter) 동작 원리와 예제

이미지
파티클 필터(particle filter)는 칼만 필터(kalman filter) 와 마찬가지로 노이즈가 있는 환경에서 측정된 데이터를 필터를 사용해 실제 위치를 추정하는 도구다. 파티클 필터(particle filter)는 보통 가우시안 분포가 아닌 측정 데이터를 다루기 위해 사용된다고 한다. 물론 가우시안 분포의 데이터에서 사용하지 말라는 건 아니다.  본 포스트에서는 파티클 필터(particle filter)의 어려운 수학적인 내용은 제하고, 쉽게 예를 들며 필터의 동작원리에 대해 알아보았다. 파티클 필터(particle filter)에 대해 검색해 보면 아래와 같은 그림을 많이 보게 된다. 아래 그림은 파티클 필터의 estimation cycle을 도식화한 것이다. <’Real-Time Tracking of Multiple Moving Objects Using Particle Filters and Probabilistic Data Association’ original scientific paper 中> 위 그림의 검은색 원들은 particle을 의미한다. 이 particle에는 보통 위치 데이터와 weight가 포함된다. 검은색 원이 큰 것이 있고 작은 것이 있는 이유는 weight가 크고 작음을 의마한다. typedef struct _particle_t {    int x;    int y;    float weight; }particle_t; 노이즈가 있는 환경에서 레이저 센서나 레이더등을 이용하여 물체의 위치를 측정할 때를 가정해 순서대로 이 필터가 동작하는 과정에 대해 알아 보겠다. (순서는 위 그림과 조금 다르다) 1. 초기 상태 측정 범위안에 랜덤 혹은 일정한 간경으로 particle을 뿌려 놓는다. 이 떄 particle의 weight는 모두 0으로 한다.   for(i
자세한 내용 보기

아두이노(arduino) 심박센서 (heart rate sensor) 심박수 측정 example code

이미지
하드 정리 중 예전에 만든 아두이노에서 심박센서를 사용하여 심박수 측정하는 소스 코드가 있어, 이를 블로그 글로 남긴다. 인터넷 쇼핑몰에서 쉽게 구할 수 있는 저렴함 센서가 사용 되었으며, 연결은 아래 그림과 같이 연결 되었다.      심박센서의 하트 부위에 손가락을 올려 놓고, 아날로그 A0값을 읽으면 심박의 움직임에 따라 A0값이 변하는 동작이 간단한 센서이다. 아래 그림의 왼쪽은 일정 시간 간격 마다 A0값을 읽어 시리얼 플로터로 본 심박에 따른 데이터이고, 오른쪽은 평균 필터를 사용해 노이즈를 제거한 후 시리얼 플로터로 본 데이터이다.   심박수는 수집된 데이터에서 threshold를 넘는 peak들의 시간 간격을 측정하여 계산한다.  peak위치를 찾는 방법은 여러 가지 방법이 있으나, 소스에 구현된 방법은 신호의 기울기가 +에서 0또는 -로 바뀌는 위치를 peak으로 선정하도록 하였다. 심장이 t시간동안 N회 뛰는 경우 심박수는 heart rate bpm = (N/t)*60 을 표현 할 수 있다.   threshold는 데이터를 보고 임의로 정했으며, 측정 데이터에 따라 자동으로 정하고 싶을 때는 cfar 같은 방법을 사용하면 된다.  소스는 아래와 같다. #define heartbit_adc_threshold      511 #define meanfilter_size             5 #define heartbit_tick_buffer_size   10 #define measure_buffer_size       3 float meanfilter[meanfilter_size] = {0,};
자세한 내용 보기

간단한 cfar 알고리즘에 대해

이미지
Constant False Alarm Rate (CFAR)은 기본적으로 테스트하고자 하는 위치의 cell과 주변 cell의 관계를 보고 테스트 cell이 Target 인지 아닌지를 구분하는 알고리즘이다. 주변 cell과의 관계를 어떤 방식으로 비교하는가에 따라 여러가지 알고리즘이 존재한다. CA-CFAR, GO-CFAR, SO-CFAR, OS-CFAR, VI-CFAR, OSVI-CFAR등이 있다. 이 많은 알고리즘 중 간단하고 기본적인 CA-CFAR과 OS-CFAR에 대해 알아보자. CA-CFAR (Cell Average CFAR)   CA-CFAR의 원리는 위 그림과 같다. 좌우의 Reference Cell의 평균에 Scale Factor T를 곱하고, ADT (Average Decision Threshold)를 합하여 CUT가 타겟인지 아닌지를 구분한다. ADT는 신호의 white noise를 고려하기 위해 더해준다. Scale Factor T와 ADT는 아래와 같은 공식으로 사용할 수 있다. 사용하려는 시스템에 따라 공식은 달라질 수도 있다.   Pfa는 False Alarm 발생 확률을 나타내고, M과N는각 좌우의 Reference Cell의 개수를 나타낸다. OS-CFAR (Order Static CFAR)   OS-CFAR의 원리는 위 그림과 같다. 좌우의 reference cell중 K번째 큰 값의 cell을 Reference Cell의 대표 값으로 정해 CUT가 타겟인지 아닌지를 구분한다. 보통 전제 reference cell의 크기 순에서 (3*N)/4 번째 cell이 성능이 좋다고 알려져 있다. CFAR 사용 예 아래 사진은 위 두 cfar을 사용한 예다. 파란색은 신호이며, 붉은 색은 char을 사용해 만든 threshold이다. 이 threshold보다 큰 값의 신호가 있는 위치에 실제 Target이 있다고 볼 수 있
자세한 내용 보기

windows에서 간단하게 크롬캐스트(Chromecast)를 통해 윈도우 화면 미러링 방법

이미지
 Windows 10에서는 미라캐스트를 사용한 무선 디스플레이연결을 지원한다. 하지만, 만약 크롬캐스트(Chromecast)를 사용해 윈도우 화면을 미러링 하고자 할 때, 구글 크롬 브라우저를 사용하면 쉽고 편하게 할 수 있다. https://www.google.co.kr/intl/ko/chrome/ VLC에서도 비디오 화면을 미러링 할 수 있다고 하는데, 잘 동작하지 않고 윈도우 화면 전체를 미러링하지 않아 크롬 브라우저를 사용하고 있다. 크롬 캐스트 윈도우 화면 전송 방법 0. 크롬 캐스트 디바이스와 windows pc는 같은 네트웍에 연결되어 있어야 한다. (같은 공유기에 연결되어 있어야 한다.) 1. 크롬 브라우저의 우측 상단의 메뉴 > 전송을 클릭하면, 현재 사용가능한 크롬캐스트 디바이스 항목을 볼 수 있다. 2. 편의에 따라 탭 전송 아이콘에서 우측 버튼을 클릭하여 항상 표시되게 설정할 수도 있다. 3.  윈도우 화면 전체를 전송하고자 할 때는 탭 전송의 소스에서 '데스크톱 전송'을 선택하고, 바로 위의 크롬캐스트 디바이스를 클릭하면 된다. ** 소스는 미러링 중에는 변경되지 않는다. 먼저 소스를 선택하고 미러링해야 한다.  4. 화면 전송을 끝내고자 할 때는, 탭 전송에서 화면 전송중인 크롬캐스트 디바이스를 클릭하거나, 크롬 브라우저를 종료하면 된다.
자세한 내용 보기

리눅스 디바이스 드라이버 기초와 예제

이미지
▢  디바이스 드라이버  디바이스 드라이버는 시스템이 지원하는 하드웨어를 사용자가 응용 프로그램에서 사용할 수 있도록 커널의 일부 영역을 사용하여 동작하는 일종의 프로그램이다.   리눅스에서 사용자가 커널 모드의 디바이스 드라이버를 사용하여 실제 하드웨어 디바이스에 접근하고자 할 때 아래 그림과 같은 추상적인 계층들을 통과해야 한다.    리눅스 사용자 관점에서 디바이스는 하나의 파일로 인식된다. 이런 파일들은 /dev 디렉토리에 위치하며, 이들을 디바이스 파일이라고 한다.    디바이스 드라이버는 문자/블록/네트워크 디바이스 드라이버 세 종류가 있으며, 각 디바이스는 주 번호(Major number)와 부 번호(Minor number)를 갖고 있다.  문자 디바이스 (Char Device) 자료의 순차성을 지닌 장치로 버퍼 캐쉬를 사용하지 않으며, 장치의 raw data를 사용자에게 제공한다. 시리얼, 키보드, 프린터, 마우스 등이 이에 속한다.  블록 디바이스 (Block Device) Radom access, 블록 단위의 입출력이 가능하고, 파일 시스템에 의해 mount 되어 관리되는 장치. 디스크, CD-ROM등이 이에 속한다.  네트워크 디바이스 (Network Device) 대응하는 장치 파일 없으며, 네트워크 통신을 통해 패킷을 송수신할 수 있는 장치. 이더넷 등이 이에 속한다.    ▢  커널 모듈 커널 모듈은 리눅스 커널이 부팅되어 동작 중일때도 동적으로 추가하거나 제거할 수 있는 커널의 구성요소이다. 디바이스 드라이버, 파일 시스템, 네트워크 프로토콜 등이 모듈로 제공된다.  커널 모듈은 커널 영역에서 동작한다. 일반 응용프로그램과 달리 main함수가 없으며, 모듈이 적재될 때와 해지될 때 호출되는 함수가 존재한다.  module_init(hellomodule_init);
자세한 내용 보기