Loại tin nhắn nào có thể được sử dụng cho các giao thức IoT định hướng mạng di động?

Điều này khiến tôi chú ý gần đây khi tôi tìm thấy một video tuyệt vời trên Youtube bằng cách:

Micheal E. Anderson: So sánh các kỹ thuật nhắn tin cho IoT, OpenIoTSummit, Linux Foundation .

Các slide cho bài nói chuyện của anh ấy có sẵn ở đây

Trên Slide 26 và 41 phút của video, anh ấy đang thảo luận về cách thức (hãy để tôi diễn giải):

Các nhà mạng di động thích rằng người tiêu dùng IoT của họ sử dụng loại thông điệp HTML , XML hoặc JSON vì họ tiêu thụ nhiều Dữ liệu hơn. Nhiều dữ liệu hơn có nghĩa là họ có thể tính phí cho người tiêu dùng nhiều tiền hơn cho dịch vụ.

Tôi hiểu rằng rất nhiều giao thức độc quyền viz. SigFox , Wireless HART hoặc Z Wave có tốc độ dữ liệu thấp hơn và việc gửi dữ liệu cồng kềnh qua các nhà mạng như vậy có thể là một vấn đề đắt đỏ.

Câu hỏi

• Có một số định dạng nhắn tin trọng lượng nhẹ khác đang được sử dụng để sử dụng trong Giao thức sở hữu độc quyền khiến chúng trở thành giải pháp tiết kiệm chi phí cho người tiêu dùng IoT hiện tại và tương lai? (Chụp trong bóng tối: một số định dạng được gọi là XML hoặc HTML hoặc JSON nhẹ nằm ở đâu đó?)

• Có lẽ một cái gì đó như CBOR là hoặc có thể được sử dụng?

Bạn đang hỏi về giao thức hoặc định dạng tin nhắn ? Chúng tôi thường sử dụng không chính xác giao thức hạn khi chúng tôi muốn nói đến định dạng của dữ liệu. Tôi tự làm điều này, thường bởi vì sự khác biệt không rõ ràng với mọi người.

Các giao thức nhắn tin được sử dụng trong IoT có xu hướng khá nhỏ gọn, ít nhất là hơn http và cung cấp các tính năng quan trọng quan trọng trong nhắn tin (phiên, kiểm soát luồng, độ tin cậy, v.v.). Định dạng tin nhắn là dữ liệu trong tin nhắn được gửi. Tôi cho rằng đây là những gì bạn đang hỏi về.

Định dạng tin nhắn nhỏ gọn nhất là định dạng nhị phân cuộn được xem xét cẩn thận. Nó thường được sử dụng khi trong các kịch bản băng thông thấp khi bạn muốn gửi một vài byte và biết chính xác những byte đó trông như thế nào. Đối với các tin nhắn lớn hơn, các nhược điểm là đáng kể và, nói chung, nên tránh bằng mọi giá.

Tôi đã trải qua một đánh giá chi tiết về nhiều tùy chọn tuần tự hóa dữ liệu khác nhau. Tôi mong đợi protobuf, gói tin nhắn khá nhỏ gọn. Tuy nhiên, vấn đề thứ hai của tôi là tìm các thư viện được duy trì và có sẵn trên một số nền tảng khác nhau, bao gồm cả C trên thiết bị.

Định dạng mà tôi giải quyết, đáng ngạc nhiên, là gzip nén JSON. Thật dễ dàng để thực hiện và hiểu, chạy ở mọi nơi và, với dữ liệu mà tôi đang sử dụng, gần giống hoặc nhỏ hơn các phương thức khác.

Ngoài ra, hãy cẩn thận nếu bạn có một kênh bảo mật như TLS, dù sao bạn cũng sẽ tiêu thụ một khối dữ liệu (> 6KB) trong các bắt tay TLS.

Vài năm trước, tôi mong đợi một định dạng như bộ đệm giao thức sẽ thống trị, nhưng không thực sự xảy ra nhiều. Có lẽ vì sự dễ dàng mà json có thể được viết ra và phân tích cú pháp (và nén). Tôi thích giao diện của Flatbuffers , nhưng ưu điểm là tốc độ phân tích cú pháp nhiều hơn là nhỏ gọn.

Vì bạn đang ở giai đoạn điều tra, tôi khuyên bạn nên viết một chút mã trên mỗi mã, sử dụng dữ liệu điển hình cho tình huống của bạn và thực hiện một số so sánh. Có dữ liệu cứng khi bạn bắt đầu giúp xác nhận lựa chọn của bạn.

Ưu điểm lớn của định dạng dựa trên đánh dấu là bạn giữ được sự linh hoạt trong việc lựa chọn dữ liệu nào bạn truyền tải. Điều này cực kỳ quan trọng trong một hệ sinh thái đang phát triển nơi bạn dự đoán một dịch vụ phát triển qua nhiều năm phát triển.

Mặc dù cấu trúc dữ liệu nhị phân được mã hóa chặt chẽ sẽ có hiệu quả để truyền, bạn cần quyết định trước tối thiểu cấu trúc sẽ trông như thế nào. Khi, sau này bạn nhận ra rằng ngay cả một lĩnh vực cũng cần mở rộng, bạn sẽ bị mắc kẹt. Ngay cả việc tung ra một bản cập nhật cho giao thức cũng khó, vì bạn không thể lỗi thời mã hóa cũ cho đến khi mọi điểm cuối được cập nhật.

Điều này cho thấy cách tiếp cận tối ưu là trộn các gói tối giản và mã hóa dựa trên đánh dấu (sử dụng cái sau làm dự phòng). Giá trị của điều này phụ thuộc vào tải trọng băng thông cao nhất. Nếu bạn đã chuyển các đoạn có kích thước video thường xuyên, tối ưu hóa dữ liệu kiểm soát không thường xuyên sẽ ít đáng giá hơn. Nếu bạn có các lần chuyển nhỏ thường xuyên (có thể là nhiệt độ), sẽ rất hợp lý để giảm thiểu chi phí trong quá trình truyền - nhưng có thể chỉ cần thực hiện các đợt chuyển là tốt.