Constrained Things

올해 초부터 CoAP 기반의 Firmware-over-the-Air 솔루션을 독자적으로 개발하고 있다. 사실 핵심 기술은 거의 완성했다. 델타 스크립트 생성기술, 델타 전달 프로토콜, 데이터 저장 및 무결성 확인 절차, 그리고 델타 업데이트와 복구를 지원하는 부트로더까지. 나는 2019년 11월 13일 뉴욕에서 열리는 ACM SenSys 2019 에서 이 기술을 시연하려고 한다.

나는 이 기술이 절실했기 때문에 개발했다. 대규모 무선 센서 네트워크 기술을 개발 중, 소스코드를 수정할 때마다 IoT 디바이스 100대의 펌웨어를 업데이트시켜야 했다. 유선 펌웨어 업데이트는 노가다였다. 한 번에 한 디바이스씩 업데이트할 수밖에 없었다. 기기 하나씩 하나씩 손수 JTAG선을 연결해서 업로드했다.  100대 디바이스를 모두 업데이트 하는데 보통 40분씩 걸렸다. 그렇게 업데이트를 해서 네트워크가 제대로 동작하면 좋은데…. 보통은 그렇지도 않았다. 코드 한 줄만 실수해도 다시 40분을 버리는 것이었다. 이런 시간 낭비를 없애고 싶었다.

앞으로 내 FOTA 프로토콜에 대해서 글을 써 보려 한다. 아직 미흡한 부분들이 많은데, 글을 쓰면서 그 부분들을 채우는 방법도 고민해볼 것이다.

IEEE 논문은 형식에 맞춰 제출해야 한다.

IEEE 에서 제공하는 논문 템플릿은 2단 레이아웃에 각주는 왼쪽 단에만 있다.

그런데 이 소프트웨어는 저장만 하면 지멋데로 레이아웃을 수정한다.

각주가 두 단에 걸쳐 나타나는 것이다.

이런 문제에 대한 해결법을 찾고자 했다.

공식 홈페이지에 비슷한 질문이 여럿 나와있는데, .doc 로 저장하라는 둥 수준 이하의 답변밖에 없었다.

방법을 요약하겠다.

1. ALT+F11 누름 -> VBA Editor 열림

2. CTRL+G 누름 -> 하단에 "직접 누름" 창 열림 

3. "직접 누름" 창에 다음을 입력 후 엔터: ActiveDocument.SetCompatibilityMode 14

4. VBA Editor 닫고, 파일->옵션->고급->호환성 옵션->다음 프로그램에서 만든 것처럼 레이아웃 저장-> Microsoft Word 2010 ->확인 

이 작업을 마치면 각주가 왼쪽 단에 고정된다.

문서가 워드2010에서 편집된것처럼 레이아웃이 재정렬되기 때문이다.

이 문제로 고생하는 사람에게 이 글이 도움되길 바란다.

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

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

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

서버에서 atomic 방식의 블록형 요청 페이로드(예: PUT/POST) 를 수신하는 경우, 최종 블록, 즉 M 비트가 0 인 Block1 옵션을 포함한 블록이 수신되었을 때 실제 작성/대체가 이루어집니다. 이 경우, 최종 블록이 아닌 모든 성공 응답은 응답 코드 2.31 (Continue)을 반환합니다. 마지막 블록을 처리 할 때, 서버에서 모든 이전 블록들이 가용하지 않다면, 전송은 실패하며 오류 코드 4.08 (Entity Incomplete Request)이 반드시 반환되어야 합니다. 서버는 비순차적인 임의의 (최종 또는 비 최종) Block1 전송에 대해 4.08 오류 코드를 반환할 수도 있습니다. 따라서, 이 경우를 처리할 특정 메커니즘이 없는 클라이언트는 항상 블록 0 을 시작으로 블록들을 순서대로 전송해야 합니다.

클라이언트가 4.08 오류 코드를 수신하는 이유중 하나는, 서버에서 시간이 초과되어 부분 요청 내용을 폐기했기 때문입니다. 클라이언트는 과도한 지연없이 요청을 구성하는 모든 블록을 보내려고 노력해야 합니다. 서버는 가장 최근 블록이 전송 된 후 EXCHANGE_LIFETIME 이 경과하면 부분 요청 본문을 마음껏 버릴 수 있습니다. 그러나 서버에서 항상 부분 요청 본문을 오래 보관할 필요는 없습니다.

atomic 방식의 블록형 요청 페이로드 전송에서, 서버는 블록 저장에 필요한 자원이 없는 경우 오류 코드 4.13 (요청 엔티티가 너무 큼) 을 언제든지 반환 할 수 있습니다. (Block1 을 사용하지 않는 요청에 대한 4.13 응답은 클라이언트에게 Block1 로 전송해보라고 하는 힌트이며, 요청한 SZX 보다 더 작은 SZX이 들어있는 Block1 옵션이 포함된 4.13 응답은 더 작은 SZX 로 요청해 달라는 힌트임을 유의하십시오.)

stateless 방식의 블록형 요청 페이로드 전송에서, 서버는 전송이 진행중이거나 클라이언트로부터 전송이 완료되지 않은 동안 비일관적 상태에서 운영될 수 있습니다.  이 특성은 전송 중 서버에 state 가 항상 유지되는 HTTP 보다는 원격 파일 시스템의 특성에 더 가깝습니다. 공유 파일 액세스 (예: 클라이언트 특정 임시 리소스)에서 잘 알려진 기술을 사용하여 HTTP 와의 차이를 완화 할 수 있습니다.

Block1 옵션은 단일 종단점이 동일한 자원에 대해 동시에 여러 개의 블록 방식 요청 페이로드 전송 (예 : PUT 또는 POST) 작업을 수행 할 수있는 방법을 제공하지 않습니다. 동일한 종단점의 이전 시퀀스가 완료되기 전에 동일한 자원에 대한 새로운 블록 단위의 요청을 시작하면 서버가 계속 유지할 수있는 컨텍스트를 단순히 덮어 씁니다.