XMPP가 짧고 빈번한 메시지를 보내는 IoT 장치에 대한 오버 헤드가 크나요?

IoT 장치의 잠재적 통신 프로토콜로 XMPP에 대해 읽었지만 소스를 읽은 후에 각 메시지의 오버 헤드에 대해 걱정할 경우 실제로 적합한 프로토콜인지 확실하지 않습니다.

이 출처 는 다음과 같습니다.

그러나 XMPP에는 EMBEDDED IOT PROTOCOLS에 바람직하지 않은 여러 가지 문제가 있습니다. XML 기반 프로토콜 인 XMPP는 HTTP보다 훨씬 장황하며 데이터 오버 헤드가 심합니다. IOT CONNECTED DEVICE에서 서버로 1 바이트의 데이터를 전송하기위한 단일 요청 / 응답 교환이 0.5kB 이상입니다.

효율적인 XML 교환 (EXI)이라는 XML 인코딩을 사용하여 XMPP를 압축하는 사양 초안이 있습니다. 그러나 EXI에서도 동일한 1 바이트의 데이터는 XMPP만으로도 수백 바이트의 프로토콜 오버 헤드를 얻습니다. EXI는 현재 사용 가능한 다른 옵션보다 처리하기가 훨씬 어려운 형식입니다. 이러한 고유 한 문제로 인해 일반적으로 임베디드 IoT 애플리케이션에서 XMPP를 사용하지 않는 것이 좋습니다.

그러나 XMPP 는 IoT 응용 프로그램에 적합한 것으로 자체 홍보합니다 (특히 오버 헤드가 낮다는 것은 아니지만) IoT 장치에 대해 그렇게 크고 장황한 프로토콜이 권장 / 홍보 될 가능성이 높습니다.

XMPP의 오버 헤드가 소스에서 소량의 데이터에 대해 제안한 것만 큼 큰가요? 예를 들어, 8 바이트 메시지를 보낼 때 얼마나 많은 오버 헤드가 있습니까?

또한 EXI 압축을 사용하면 (소스에서 언급 한) 오버 헤드가 너무 큽 니까? 이것도 함정이 있습니까?

communication networking xmpp

— Aurora0001
소스

흥미로운 질문입니다. XMPP에 익숙하지는 않지만 EXI에는 두 엔드 포인트 모두 동기화해야하는 스키마가 있어야합니다. 또한 IoT 장치는 XML을 인코딩 / 디코딩해야하므로 8 바이트 메시지를 보내기에는 그 자체가 매우 복잡해 보입니다.

— Helmar

실제로 @Helmar, XMPP를 사용하면 패킷 크기에서 얻는 것과 같이 계산 복잡성이 줄어 듭니다.

— Aurora0001

이 질문은 일반적으로 문제가 없지만 "예를 들어, 2 분마다 8 바이트 메시지를 보낼 때 얼마나 많은 오버 헤드가 발생합니까?" -> "2 분"은 접선이며 사물을 잃어 버리는 경향이 있습니다. 당신이 정말로 요구하는 것은 8 바이트 메시지가 얼마나 많은 오버 헤드를 가지고 있는지입니다 (1 바이트 메시지와 동일한 데이터 일뿐이라면 추측합니다). 시간 구성 요소와 관련하여 이것은 단순히 대역폭에 의존하며 단순한 단순한 수학 이어야 하는 네트워크 프로토콜의 사용을 고려하는 사람에게 달려 있습니다.

— goldilocks

@delicateLatticeworkFever 관련이 없다고 생각되면 수정하겠습니다. (전적으로 확신하지는 않았지만 자세한 내용은 더 적을 것보다 낫습니다.)

— Aurora0001

그것은 제안입니다. 내가 읽은 것을 읽는 것만으로도, "결정되지 않은 바이트 수를 보내는 데 완전히 지정되지 않은 장치가 얼마나 오래 걸리는가에 달려 있지 않습니까?" 예를 들어, 메시지가 ~ 0.5 kB라는 답이 있다면 단위에 시간 요소가 없습니다.) 그것은 지정되지 않은 장치의 대역폭에 있습니다.

— goldilocks

답변:

XML이 장황하다고 말할 수는 있지만,이 장황한 내용이 의미론을 캡슐화하기 때문에 내용과 관련하여 모든 "오버 헤드"가 아니라는 점을 염두에 두어야합니다. 정적 구조가 아닌 역 동성을 강조하는 프로토콜의 증상은 오버 헤드입니다. 예를 들어 HTML은 실제로 컨텐츠의 한 측면으로 간주 될 수있는 동적 구조, 구조를 사용하여 컨텐츠를 전달하는 편안한 XML 형식입니다. 테이블의 내용을 테이블 자체와 구별 할 수 있지만 내용이 특정 관계를 갖는 테이블 형식의 데이터라는 사실은 내용에 필수적입니다. 방금 각 셀을 가져 와서 하나의 긴 문자열로 전송하면 해당 구조와 관계가 사라져서 정보를 잃어 버렸습니까?

타블로 어 데이터를 구성 할 수있는 8 바이트 메시지를 생각해 봅시다. 매우 정적 인 프로토콜을 사용하는 경우 최소한 다음과 같은 프로토콜을 정의하여 추가 오버 헤드없이 전송할 수 있습니다.

각 메시지는 정확히 8 바이트이므로 길이를 나타내거나 종료 시퀀스를 포함 할 필요가 없습니다.
8 바이트는 항상 각 셀에 16 비트 값이 포함 된 2 x 2 그리드를 나타냅니다.

모든 메시지가 정확히 그런 경우 XML, HTML 또는 XMPP를 사용하는 것은 어리석은 것으로 간주 될 수 있습니다. 어쨌든 항상 동일하고 미리 결정된 구조적 구성 요소에 대역폭을 낭비하고 있으며,이를 작성하고 구문 분석하는 양쪽 끝에 해당 계산 시간을 낭비하고 있습니다. 각 셀에 두 개의 문자가있는 2 x 2 테이블 만 포함 된 최소의 적절한 HTML 페이지는 서식 및 프로토콜 오버 헤드를 수용하기 위해 최소 100 바이트가 될 것입니다.

그러나, 모든 메시지가 정확히 그런 것이 아니라면, 어떤 종류의 메시지인지 지정하는 것은 "페이로드"의 문자적인 부분이 아닐 수 있지만 컨텐츠 측면에서 필요한 구성 요소입니다. 나는 여분의 2 바이트로 그렇게 할 수 있고 훨씬 더 역동적 인 것을 소개 할 수 있습니다.

메시지는 이제 가변 길이 (0-255 바이트)이며 첫 번째 바이트는 길이를 나타냅니다.
미리 정의 된 다른 메시지 유형에 대해 최대 256 개의 코드가 있으며 그 중 하나는 "2 x 2 테이블"이며 두 번째 바이트입니다.

이제 8 바이트의 테이블 내용에 2 바이트의 오버 헤드가 필요하지만이 사용자 지정 프로토콜을 사용하여 어떤 종류의 메시지를 보낼 수 있는지에 대한 가능성은 훨씬 더 넓습니다.

그것은 여전히 HTML 페이지 또는 XML 네임 스페이스 사양 (또는 XMPP가 본질적으로있는 것 ) 의 가능성에 가깝습니다 .

따라서, 당신이 주로하는 일이 간단한 8 바이트 메시지를 보내는 것이라면, XMPP는 아마도 과잉 일 것입니다. 그러나 반드시 그런 것은 아닙니다. "IOT 연결 장치에서 서버로 1 바이트의 데이터를 전송하기위한 단일 요청 / 응답 교환이 0.5kB 이상"이라는 주장은 관련 RFC 에 대해 과장되어 잠재적 인 과장된 것으로 보입니다. 나는 그것을 보았습니다 .XMPP를 구현하거나 사용하지 않았습니다). 나는 당신이 그러한 예를 만들 수 있다는 것을 의심하지는 않지만 아마도 최소한의 예 는 아닙니다 .

프로토콜은 TCP 지향적이므로 " 'jabber : client'네임 스페이스로 규정 된 XML 스트림"을 설정하는 것은 우리가 한 가지 일을하는 경우에만 메시지의 일부로 간주하면됩니다. 장치는 서버에 연결하여 8 바이트를 보내고 데이터 연결이 끊어집니다. 관계가보다 영구적이며 종종 IoT 상황에있을 경우 장치가 대상에 이미 연결되어 있다고 가정 할 수 있습니다. 이 경우, 메시지의 최종 목적지가 서버 인 경우 (다른 클라이언트와 달리 서버가 메시지를 전달할 경우) 프로토콜 오버 헤드가 최소화됩니다.

<message><body>8 bytes.</body></message>

33 바이트의 "오버 헤드" 여기서 XML은 텍스트라는 점을 지적 할 필요가 있습니다. 따라서 메시지가 종종 바이너리 인 경우 데이터가 인코딩되어야 (예 : base64 ) 더 많은 오버 헤드와 계산을 추가 해야하기 때문에 훨씬 덜 적합해질 것입니다 요구 사항.

따라서 궁극적으로 :

XMPP가 짧고 빈번한 메시지를 보내는 IoT 장치에 대한 오버 헤드가 크나요?

지속적인 연결이 있고 메시지가 대부분 구조화되어 있지 않다면 그렇게 생각하지 않습니다. 그러나 그것이 제공하는 것 (구조와 관련된 역 동성)이 필요하지 않다면 아마도 더 적절한 방법론이있을 것입니다.

이를 위해 단일 중앙 서버가 다양한 장치간에 메시지를 처리 및 / 또는 의존하는 컨텍스트가있는 경우 해당 장치 중 하나가 수행하는 작업이 항상 간단하고 간단하더라도 다양한 메시지가 여전히 유용합니다. 클라이언트 장치에 제한된 리소스가있는 경우 많은 프로토콜을 하드 코딩 할 수 있으며 각 끝에서 각 메시지를 래핑하는 것은 매우 간단한 작업이됩니다. HTTP 서버를 배포하는 많은 IoT 장치가 그렇게합니다 ( "단순 클라이언트, 복잡한 서버"의 반대). 이러한 서버는 어떤 형식의 HTTP 요청도 처리 할 수 없으며 (사전 형식화 된 거부를 제외하고) 수행 할 작업과 응답이 매우 잘 정의되어 있고 집중적이지만 일련의 HTTP 요청은 HTTP 서버처럼 올바르게 작동하므로,

— 미역취 속의 일종
소스

우선, XML은 실시간 메시지를 성공적으로 캡슐화하는 데 사용되었으며 특히 XMPP에서 IM과 현재 상태를 전달하는 데 사용되었습니다. 또한 XML 지식을 활용하여이 데이터 표현 시스템을위한 또 다른 응용 분야를 찾으려고하는 일부 회사도 있습니다.

그러나 XML이 메시징 시스템의 모든 것에 대한 해답이라고 모든 사람이 확신하는 것은 아닙니다. 예를 들어, 최근 XML을 사용하지 않고 데이터를 직렬화하는 방법으로 JSON을 사용하는 온라인 시스템으로 눈에 띄는 변화가 있었으며 개발자 모자를 잠시 켜면 네이티브에서 인코딩 / 디코딩하는 도구라고 말할 수 있습니다. XML (예 : Python, PHP, Javascript)은 XML이 해당 답변을 올바르게 얻는 데 더 많은 시간이 있었음에도 불구하고 JSON에 비해 XML보다 동등합니다.

XML은 비교적 복잡한 텍스트 파서가 필요하고 컴퓨터에서 데이터를 프로그램에서 추출 할 수있는 일종의 계층 적 표현이 필요하기 때문에 컴퓨터가 다루기 어려운 표현입니다. 텍스트가 너무 많기 때문에 인코딩 / 디코딩에 사용할 수있는 메모리가 약간 필요합니다.

XML이 데이터 표현에 많은 가치를 부가한다는 것은 불분명합니다. 만약 핵심 메시지가 깊게 계층 적이 지 않다면, 많은 텍스트 조각을 추가하는 것은 불필요 해 보이지만, 많은 계층 구조가 있다면 역설적으로 메시지를 해독합니다. 텍스트 표현은 열심히 일하고 많은 리소스가 필요합니다. 또한 텍스트로 표현하는 것의 이점은 명확하지 않습니다. 통신 시스템을 처음 작성하고 디버그 할 때 모니터링 / 디코딩 도구 (예 : Wireshark)를 사용하여 무엇이 잘못되었는지 파악하는 것이 일반적입니다. 장기적으로는 모든 것이 잘 작동하므로 사람은 컴퓨터에서주고받는 메시지를 자세히 볼 필요가 없습니다. 컴퓨터는 이진 표현을 선호합니다. 텍스트 표현은 배포 단계에서 아무도 관여하지 않습니다.

XML은 사람이 컴퓨터에서 동시에 열심히 일하는 동안 읽기 (및 수동 구성)하기가 어렵습니다. 따라서 컴퓨터에는 적합하지 않으며 인간에게는 적합하지 않은 시스템입니다.

중요하게도 IoT에는 효율적으로 만드는 데 특별한 제약이 있습니다. IoT 장치는 일반적으로 처리 능력과 스토리지가 제한적입니다 (대개 대규모 보조 스토리지가없고 일부 RAM과 EEPROM 만). IoT 장치는 가장 간단한 통신 링크를 가질 수 있으며 TCP / IP 스택조차도 아닐 수 있습니다. 표준 운영 체제 (예 : Linux, Android)가 사용되는 정교함 수준이 아닌 다양한 마이크로 컨트롤러 설계가있을 것입니다. 이는 사용하기 쉬운 XML 인터페이스를 제공하는 상용 도구의 수를 제한합니다.

요약하자면, IoT의 경우 하드웨어 제약, 통신 스타일 (예 : 브로드 캐스트, 데이터 그램, 신뢰성 등), 통신 빈도 등에 따라 사례별로 데이터 표현이 더 나은 것으로 생각됩니다. XML은 확실히으로 생각해서는 안된다 사인 ...로서 비 의 IoT합니다.

— TheMagicCow
소스

몇 년 전 나는 사용에 대한 차이점을 분석했다

기존과 비교하여 지불 트랜잭션 표현 (card_number, date, time, terminal_id 및 추가 요소 목록)을위한 지불 네트워크의 XML

비트 맵 ISO8583
XML에는 엄청난 오버 헤드가 있습니다. 각각 10000 개 이상의 노드가있는 네트워크에서 각 호스트가 시간당 / 일마다 10 개 이상의 메시지를 중앙 호스트에 보내는 영향을 고려하면 XML이 종료되고 더 효율적인 것이 필요합니다.

— 부밋 아 미트
소스