CoAP Block2 옵션 사용하기

M 비트가 설정된 Block2 옵션이 포함된 응답을 수신한 요청자는 초기 요청과 동일한 옵션으로 추가 요청을 보내고 블록 번호와 블록 크기를 제공하는 Block2 Option을 보내어 자원 표현의 추가 블록을 검색 할 수 있습니다. 요청시 클라이언트는 반드시 Block2 옵션의 M 비트를 0으로 설정해야 하며 서버는 수신시 반드시 이를 무시해야 합니다.

CLIENT                                                    SERVER
|                                                            |
| CON [MID=1234], GET, /status                       ------> |
|                                                            |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128            |
|                                                            |
| CON [MID=1235], GET, /status, 2:1/0/128            ------> |
|                                                            |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128            |
|                                                            |
| CON [MID=1236], GET, /status, 2:2/0/128            ------> |
|                                                            |
| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128            |

Simple Block-Wise GET

응답에서 사용되는 블록 크기를 조절하기 위해, 요청자는 초기 요청에서 Block2 Option 을 사용할 수 있습니다. 이 때 옵션값에는 원하는 크기, 블록 번호 0, M 비트에는 0을 넣습니다. 서버는 반드시 표시된 크기 또는 더 작은 크기의 블록을 사용합니다. 첫 번째 요청 블록 다음의 블록 단위 요청들은 반드시 서버로부터 온 첫번째 응답에서 받은 Block2 Option에서 제공된 사이즈를 나타내야 합니다.

CLIENT                                                     SERVER
|                                                          |
| CON [MID=1234], GET, /status, 2:0/0/64           ------> |
|                                                          |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64           |
|                                                          |
| CON [MID=1235], GET, /status, 2:1/0/64           ------> |
|                                                          |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64           |
:                                                          :
:                          ...                             :
:                                                          :
| CON [MID=1238], GET, /status, 2:4/0/64           ------> |
|                                                          |
| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64           |
|                                                          |
| CON [MID=1239], GET, /status, 2:5/0/64           ------> |
|                                                          |
| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64           |

Block-Wise GET with Early Negotiation

일단 요청자가 Block2 Option을 사용하였고 블록 사이즈가 조정되었을 수 있는 첫번째 응답을 받았다면, 단일 블록 방식 전송 내 모든 이후의 요청은 마지막 블록의 내용이 적은 경우 (M 비트가 0) 를 제외하고 궁극적으로 같은 크기를 이용하게 될 것입니다. (클라이언트는 Block2 옵션없이 보낸 첫 번째 요청이 Block2 옵션이 포함된 응답을 받은 경우 두 번째 요청부터 Block2 옵션을 사용할 수 있다는 점을 참조하십시오.) 서버는 요청 내 옵션에서 표기된 것보다 작거나 같은 블록 사이즈를 사용하지만, 요청자는 반드시 초기 요청에 대한 응답에서 사용된 실제 블록 사이즈를 기록하여 후속 요청에서 이를 사용하도록 진행해야 합니다. 서버는 반드시 이러한 클라이언트의 동작으로 인해 한 시퀀스 내 모든 응답들이 같은 블록 사이즈를 갖도록 보장하도록 동작해야 합니다. (M 비트가 0인 마지막 블록과 초기 요청에 Block2 옵션이 없는 경우의 첫 번째 블럭을 제외)

블록 방식 전송은 완전히 정적인 표현형 (디바이스를 설명하는 스키마와 같이 시간에 따라 전혀 변하지 않는 값) 을 가진 자원을 GET 하거나, 동적으로 변화하는 자원을 위해 사용될 수 있습니다.후자의 경우, Block2 옵션은 재 조립되는 블록이 동일한 표현 버전에서 나온 것인지 확인하기 위해 ETag 옵션 ([RFC7252])과 함께 사용해야 합니다. 이 경우, 서버는 각 응답에 ETag를 포함해야 합니다. ETag 옵션을 사용할 수 있는 경우 클라이언트는 교환중인 블록의 표현을 재조합 할 때 반드시 ETag 옵션을 비교해야합니다. ETag 옵션이 GET 전송에서 일치하지 않으면, 요청자는 우선 검색했던 블록들의 갱신된 값을 검색하려고 시도 할 수 있습니다. 비효율성을 최소화하기 위해, 서버는 진행중인 요청 시퀀스에 대한 표현의 현재 값을 캐시에 보관할 수 있습니다. (서버는 요청하는 엔드 포인트와 각 블록 단위 요청에서 동일한 URI의 조합에 의해 시퀀스를 식별 할 수있습니다.) 이 명세가 서버에게 상태를 확립하라는 요구를 하지 않는다는 점을 짚어야 합니다. 그러나, 빠르게 변화하는 자원을 제공하는 서버는 클라이언트가 일관된 블록 집합을 검색하는 것을 불가능하게 만들 수 있습니다. 자원의 모든 블록을 검색하고자하는 클라이언트는 과도한 지연없이 그렇게 하려고 노력해야 합니다. 서버는 해당 상태에 대한 마지막 접근 후 EXCHANGE_LIFETIME ([RFC7252]) 시간이 지나면 자유롭게 캐시된 상태를 버릴 수 있다고 예상되나 항상 상태를 그렇게 오래 유지할 필요는 없습니다.

Block2 옵션은 단일 종단점이 동일한 리소스에 대해 동시에 다중 블럭 방식 응답 페이로드 전송 (예컨대, GET) 동작을 수행 할 방법을 제공하지 않습니다. 이것은 요구가 거의 없는 사항이지만 이를 해결 방법으로 클라이언트가 캐시 키를 변경하는 방법을 생각해 볼 수 있습니다 (예 : 같은 시맨틱으로 리소스에 액세스하는 여러 URI 중 하나를 사용하거나 프록시 안전 선택 옵션을 변경하는 방식으로).