셀룰러 네트워크 지향 IoT 프로토콜에 어떤 메시징 유형을 사용할 수 있습니까?

최근 YouTube에서 다음과 같은 놀라운 동영상을 발견했을 때이 점에 주목했습니다.

Micheal E. Anderson : IoT, OpenIoTSummit, Linux Foundation의 메시징 기술 비교 .

그의 연설 슬라이드는 여기에 있습니다

비디오의 슬라이드 26 및 41 분 에서 그는 (어떻게 말로 표현할 것인가)에 대해 논의하고 있습니다.

셀룰러 사업자는 IoT 소비자 가 더 많은 데이터를 소비하기 때문에 HTML , XML 또는 JSON 유형의 메시지를 사용하는 것을 선호합니다 . 더 많은 데이터는 소비자가 서비스 비용을 더 많이 청구 할 수 있음을 의미합니다.

나는 많은 독점 프로토콜 즉, 이해합니다. SigFox , Wireless HART 또는 Z Wave 는 데이터 전송률이 낮 으며 이러한 캐리어를 통해 대용량 데이터를 전송 하는 것은 비용이 많이들 수 있습니다.

질문

• 현재 및 미래의 IoT 소비자를위한 비용 효율적인 솔루션을 제공하는 독점 프로토콜에서 사용되는 다른 경량 메시징 형식이 있습니까? (어두운 장면에서 촬영 : 경량 XML 또는 HTML 또는 JSON 이라는 형식 이 어딘가에 있습니까?)

• 어쩌면 CBOR 와 같은 것이 있습니까?

프로토콜 이나 메시지 형식 에 대해 질문하고 있습니까? 데이터 형식을 의미 할 때 종종 프로토콜이라는 용어를 잘못 사용합니다. 나는 구별이 모든 사람에게 명확하지 않기 때문에 나는 이것을 스스로한다.

IoT에 사용되는 메시징 프로토콜은 최소한 http보다 상당히 컴팩트 한 경향이 있으며 메시징에 중요한 중요한 기능 (세션, 흐름 제어, 안정성 등)을 제공합니다. 메시지 형식은 전송되는 메시지의 데이터 형식입니다. 나는 이것이 당신이 요구하는 것이라고 가정합니다.

가장 간단한 메시지 형식은 신중하게 고려 된 수동 롤링 이진 형식입니다. 저 대역폭 시나리오에서 몇 바이트를 보내려고 할 때 자주 사용되며 해당 바이트의 모양을 정확히 알고 있습니다. 큰 메시지의 경우 단점이 심각하며 일반적으로 모든 비용을 피해야합니다.

다양한 데이터 직렬화 옵션에 대한 자세한 평가를 거쳤습니다. 나는 protobuf, messagepack이 상당히 컴팩트 할 것으로 예상했다. 그러나 두 번째 문제는 장치의 C를 포함하여 여러 다른 플랫폼에서 유지 관리되고 사용 가능한 라이브러리를 찾는 것이 었습니다.

놀랍게도 내가 정한 형식은 gzip 압축 JSON이었습니다. 구현하고 이해하기 쉽고, 어디서나 실행되며, 내가 사용하고 있던 데이터로 다른 방법과 거의 동일하거나 작습니다.

또한 TLS와 같은 보안 채널이있는 경우 어쨌든 TLS 핸드 셰이크에서 데이터 청크 (> 6KB)를 소비하게됩니다.

몇 년 전에 프로토콜 버퍼와 같은 형식이 우세 할 것으로 예상했지만 실제로는 그다지 많지 않았습니다. 아마도 json을 쉽게 작성하고 구문 분석하고 압축 할 수 있기 때문에 가능합니다. 나는 Flatbuffers 의 모양을 좋아 하지만, 장점은 소형화하는 것보다 구문 분석 속도가 더 중요합니다.

조사 단계에 있기 때문에 일반적인 상황의 데이터를 사용하여 각각에 약간의 코드를 작성하고 비교하는 것이 좋습니다. 시작할 때 하드 데이터가 있으면 선택을 확인하는 데 도움이됩니다.

마크 업 기반 형식의 큰 장점은 전송하는 데이터를 선택할 때 유연성을 유지한다는 것입니다. 이는 수년간의 개발로 서비스가 발전 할 것으로 예상되는 진화하는 생태계에서 매우 중요합니다.

엄격하게 코딩 된 이진 데이터 구조는 전송하는 것이 효율적이지만 최소한 구조의 모양을 미리 결정해야합니다. 나중에 하나의 필드에서도 확장이 필요하다는 사실을 알게되면 문제에 봉착하게됩니다. 모든 엔드 포인트가 업데이트 될 때까지 이전 인코딩을 폐기 할 수 없기 때문에 프로토콜에 대한 업데이트 롤아웃도 어렵습니다.

이것은 최적의 접근법이 미니멀리스트 패킷과 마크 업 기반 인코딩을 혼합하는 것임을 제안합니다 (후자를 폴백으로 사용). 이 값은 최고 대역폭 페이로드에 따라 다릅니다. 이미 빈번한 비디오 크기의 청크를 전송하는 경우, 드물게 제어 데이터를 최적화하는 것이 가치가 없습니다. 작은 전송이 자주 발생하는 경우 (온도 일 수 있음) 전송시 오버 헤드를 최소화하는 것이 합리적이지만 전송을 일괄 처리하는 것이 좋습니다.