XMPP có chi phí lớn cho các thiết bị IoT gửi tin nhắn ngắn, thường xuyên không?

Tôi đã đọc về XMPP như một giao thức truyền thông tiềm năng cho các thiết bị IoT, nhưng sau khi đọc một nguồn, tôi không chắc liệu đó có thực sự là một giao thức phù hợp hay không nếu bạn lo lắng về chi phí cho mỗi tin nhắn.

Nguồn này nêu:

Tuy nhiên, XMPP có một số vấn đề khiến nó trở nên không mong muốn đối với PROTOCOLS EMBEDDED. Là một giao thức dựa trên XML, XMPP rất dài dòng, thậm chí còn hơn cả HTTP và có chi phí dữ liệu nặng. Một trao đổi yêu cầu / phản hồi duy nhất để gửi một byte dữ liệu từ THIẾT BỊ KẾT NỐI IOT đến máy chủ là hơn 0,5 kB.

Có một đặc tả dự thảo sẽ nén XMPP bằng cách sử dụng mã hóa XML được gọi là Trao đổi XML hiệu quả (EXI). Nhưng ngay cả với EXI, cùng một byte dữ liệu nhận được hàng trăm byte chi phí giao thức chỉ từ XMPP. EXI cũng là một định dạng khó xử lý hơn nhiều so với các tùy chọn khác hiện có. Do những vấn đề cố hữu này, thông thường nên tránh sử dụng XMPP trong các ứng dụng IoT nhúng.

Tuy nhiên, XMPP tự quảng cáo là phù hợp cho các ứng dụng IoT (mặc dù không nói cụ thể là nó có chi phí thấp), do đó, có vẻ lạ khi một giao thức lớn, dường như dài dòng như vậy sẽ được khuyến nghị / quảng bá cho các thiết bị IoT.

Là chi phí hoạt động của XMPP có thực sự lớn như nguồn gợi ý cho một lượng nhỏ dữ liệu không? Ví dụ, sẽ có bao nhiêu chi phí khi gửi tin nhắn 8 byte?

Ngoài ra, chi phí quá lớn nếu sử dụng nén EXI (như đã đề cập trong nguồn)? Điều này cũng sẽ đi kèm với một số cạm bẫy?

Mặc dù công bằng mà nói rằng XML là dài dòng, nhưng cần phải biết rằng sự dài dòng này không phải là tất cả "chi phí" liên quan đến nội dung vì nó gói gọn về ngữ nghĩa; đó là chi phí chung của bất kỳ giao thức nào nhấn mạnh đến tính năng động trái ngược với cấu trúc tĩnh. Ví dụ, HTML thực sự là một dạng XML thoải mái truyền tải nội dung với cấu trúc động, cấu trúc có thể được coi là một khía cạnh của nội dung. Bạn có thể phân biệt nội dung của bảng với chính bảng đó, nhưng thực tế là nội dung là dữ liệu dạng bảng với các quan hệ cụ thể là không thể thiếu đối với nội dung; nếu tôi chỉ lấy mỗi ô và truyền tất cả thành một chuỗi dài, cấu trúc đó và các mối quan hệ đó sẽ biến mất, và vì vậy tôi đã mất thông tin và đó không phải là nội dung đó sao?

Chúng ta hãy xem xét một thông điệp 8 byte có thể tạo thành một số dữ liệu tabluar. Nếu tôi sử dụng một giao thức rất tĩnh, tôi có thể, tối thiểu, truyền nó mà không cần thêm chi phí đơn giản bằng cách xác định một giao thức như thế này:

• Mỗi thông báo chính xác là 8 byte, vì vậy chúng tôi không cần chỉ ra độ dài hoặc bao gồm bất kỳ chuỗi kết thúc nào.
• Tám byte luôn được lấy để chỉ lưới 2 x 2 trong đó mỗi ô chứa giá trị 16 bit.

Nếu tất cả các thông điệp của tôi đều giống hệt như vậy, sử dụng XML, HTML hoặc XMPP có thể bị coi là ngớ ngẩn - Tôi đang lãng phí băng thông cho các thành phần cấu trúc luôn giống nhau và được xác định trước, và lãng phí thời gian tính toán tương ứng ở cả hai đầu tạo và phân tích cú pháp. Một trang HTML tối thiểu, phù hợp chỉ chứa một bảng 2 x 2 với một vài ký tự trong mỗi ô có thể sẽ có ít nhất 100 byte để phù hợp với định dạng và chi phí giao thức.

Tuy nhiên, nếu không phải tất cả các tin nhắn của tôi đều chính xác như vậy, thì việc chỉ định loại tin nhắn đó có thể không phải là một phần nghĩa đen của "tải trọng" nhưng nó là một thành phần cần thiết, khôn ngoan về nội dung. Tôi có thể làm điều đó chỉ với hai byte thêm và giới thiệu tính năng động hơn nhiều:

• Các thông báo hiện có độ dài thay đổi, 0-255 byte và byte đầu tiên cho biết độ dài.
• Có (tối đa) 256 mã cho các loại thông báo được xác định trước khác nhau, một trong số đó là "bảng 2 x 2", đó là byte thứ hai.

Bây giờ 8 byte nội dung bảng của tôi yêu cầu 2 byte phí, nhưng có nhiều khả năng rộng hơn về mặt loại tin nhắn nào có thể được gửi với giao thức tùy chỉnh này.

Nó vẫn không giống với khả năng của một trang HTML hoặc đặc tả không gian tên XML (hoặc được đặt trong đó, về cơ bản là XMPP ).

Vì vậy, dựa trên điều đó, nếu chủ yếu những gì bạn đang làm là gửi các tin nhắn 8 byte đơn giản, XMPP có thể là quá mức cần thiết. Tuy nhiên, không nhất thiết là nhiều. Khiếu nại rằng "một trao đổi yêu cầu / phản hồi duy nhất để gửi một byte dữ liệu từ THIẾT BỊ KẾT NỐI IOT đến máy chủ là hơn 0,5 kB" đối với tôi, liếc nhìn RFC có liên quan , là một cường điệu tiềm năng (nhưng nb, tất cả Tôi đã làm là liếc nhìn nó, tôi chưa bao giờ thực hiện hoặc sử dụng XMPP). Tôi không nghi ngờ bạn có thể xây dựng một ví dụ như vậy, nhưng đó có lẽ không phải là một ví dụ tối thiểu .

Do giao thức được định hướng TCP, nên việc thiết lập "luồng XML đủ điều kiện theo không gian tên 'jabber: client'" chỉ cần được coi là một phần của thông báo nếu chúng tôi thực hiện một việc - thiết bị liên lạc với máy chủ để gửi 8 byte đến, gửi các dữ liệu, ngắt kết nối. Nếu mối quan hệ bền bỉ hơn, thường xảy ra trong bối cảnh IoT, thì chúng ta có thể giả sử thiết bị đã có kết nối được thiết lập đến đích. Trong trường hợp này, nếu đích đến cuối cùng của tin nhắn là máy chủ (trái ngược với máy khách khác, máy chủ sẽ chuyển tin nhắn đến), thì chi phí giao thức là rất nhỏ.

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

33 byte "trên không". Điều đáng nói ở đây là XML là văn bản, và vì vậy nếu các thông điệp của bạn thường là nhị phân, thì nó sẽ trở nên ít phù hợp hơn, bởi vì dữ liệu đó cần được mã hóa (ví dụ, đến cơ sở64 ), điều này bổ sung thêm chi phí và tính toán yêu cầu.

Vì vậy, cuối cùng:

XMPP có chi phí lớn cho các thiết bị IoT gửi tin nhắn ngắn, thường xuyên không?

Nếu có một kết nối liên tục và các thông điệp phần lớn không có cấu trúc, tôi không nghĩ vậy. Tuy nhiên, nếu bạn không cần những gì nó cung cấp (tính năng động liên quan đến cấu trúc), thì có lẽ có những phương pháp phù hợp hơn.

Theo đuổi điều đó, nếu chúng ta có bối cảnh trong đó một máy chủ trung tâm đang xử lý và / hoặc dựa vào các tin nhắn giữa nhiều loại thiết bị, mặc dù bất kỳ thiết bị nào trong số đó đang làm có thể luôn đơn giản và dễ hiểu, một giao thức có thể gói gọn nhiều tin nhắn vẫn sẽ hữu ích. Nếu một thiết bị khách có tài nguyên hạn chế, chúng ta có thể mã hóa phần lớn giao thức và gói mỗi tin nhắn từ đầu đó trở thành một nhiệm vụ rất đơn giản; Tôi tin rằng nhiều thiết bị IoT triển khai máy chủ HTTP thực hiện điều đó (đó là nghịch đảo của "máy khách đơn giản, máy chủ phức tạp"). Các máy chủ đó không thể xử lý bất kỳ loại yêu cầu HTTP nào (ngoại trừ thông qua từ chối được định dạng trước) và có một tập hợp rất rõ ràng, tập trung vào những việc sẽ làm và phản hồi mà chúng sẽ gửi, nhưng vì chúng không hoạt động chính xác như máy chủ HTTP,

Trước hết, tôi nên nói rằng XML đã được sử dụng để đóng gói các thông điệp thời gian thực với một số thành công và ở quy mô lớn, đặc biệt là để truyền đạt IM và sự hiện diện trong XMPP. Dường như cũng có một số công ty đang có ý định tận dụng kiến ​​thức XML của họ để cố gắng tìm một khu vực ứng dụng khác cho hệ thống biểu diễn dữ liệu này.

Tuy nhiên, không phải ai cũng tin rằng XML là câu trả lời cho mọi thứ trong các hệ thống nhắn tin. Ví dụ, trong những năm gần đây đã có một sự thay đổi đáng chú ý đối với các hệ thống trực tuyến sử dụng JSON như một cách để tuần tự hóa dữ liệu thay vì XML và nếu tôi đặt mũ nhà phát triển của mình trong giây lát, tôi sẽ nói rằng các công cụ mã hóa / giải mã từ nguồn gốc biểu diễn (ví dụ như trong Python, PHP, Javascript) có vẻ dễ sử dụng hơn nhiều so với JSON so với tương đương của chúng đối với XML, ngay cả khi XML có nhiều thời gian hơn để trả lời đúng.

XML là một đại diện khó xử lý cho các máy tính, vì nó cần một trình phân tích cú pháp văn bản tương đối phức tạp và sau đó là một dạng biểu diễn phân cấp để cho phép trích xuất dữ liệu của nó trong một chương trình. Vì có quá nhiều văn bản liên quan, bạn cần khá nhiều bộ nhớ để mã hóa / giải mã.

Thông thường, có vẻ như không rõ ràng rằng XML đang bổ sung nhiều giá trị cho việc biểu diễn dữ liệu: nếu thông điệp cốt lõi không được phân cấp sâu, thì việc thêm nhiều đoạn văn bản có vẻ không cần thiết, nhưng nghịch lý là nếu có nhiều phân cấp thì giải mã thông điệp từ đại diện văn bản của nó sẽ là công việc khó khăn và cần rất nhiều nguồn lực. Ngoài ra, lợi ích của việc trình bày trong văn bản đối với tôi không rõ ràng: Khi chúng tôi lần đầu tiên viết và gỡ lỗi các hệ thống truyền thông, người ta thường sử dụng các công cụ giám sát / giải mã (ví dụ Wireshark) để giúp chúng tôi tìm ra điều gì đang xảy ra. Về lâu dài, mọi thứ đều hoạt động tốt, và không có con người sẽ cần phải xem xét chi tiết các tin nhắn qua lại (chỉ máy tính). Máy tính thích đại diện nhị phân. Các đại diện văn bản có lợi cho không ai tham gia ở bất kỳ giai đoạn triển khai.

XML rất khó để con người đọc (và xây dựng thủ công) trong khi vẫn làm việc chăm chỉ cho máy tính; Do đó, nó là một hệ thống không phù hợp với máy tính và cũng không phù hợp với con người.

Điều quan trọng, IoT có một số hạn chế đặc biệt khiến nó mong muốn có hiệu quả. Các thiết bị IoT thường sẽ có sức mạnh xử lý và lưu trữ hạn chế (thường không có bộ nhớ thứ cấp quy mô lớn, chỉ có một số RAM và EEPROM). Một thiết bị IoT có thể có các liên kết giao tiếp đơn giản nhất có thể, thậm chí có thể không có ngăn xếp TCP / IP. Sẽ có một loạt các thiết kế vi điều khiển, thậm chí không ở mức độ tinh vi, nơi một hệ điều hành tiêu chuẩn (ví dụ Linux, Android) sẽ được sử dụng; điều này giới hạn số lượng các công cụ sẵn có sẽ cung cấp các giao diện XML dễ sử dụng.

Tóm lại, tôi nghi ngờ rằng với IoT, việc thể hiện dữ liệu tốt hơn tùy theo từng trường hợp cụ thể, tùy thuộc vào các ràng buộc phần cứng, phong cách giao tiếp (ví dụ: quảng bá, datagram, đáng tin cậy, v.v.), tần suất giao tiếp, v.v. XML chắc chắn không nên được coi là một điều kiện thiết yếu cho IoT.

1. Nhiều năm trước tôi đã phân tích sự khác biệt cho việc sử dụng

   XML trong mạng thanh toán cho đại diện giao dịch thanh toán (card_number, ngày, giờ, terminal_id và danh sách các yếu tố bổ sung) so với truyền thống

   bản đồ bit ISO8583

2. XML có chi phí rất lớn. Nếu bạn xem xét tác động trong các mạng có hơn 10000 nút, mỗi nút sẽ gửi hơn 10 tin nhắn hàng giờ / hàng ngày đến máy chủ trung tâm thì XML sẽ biến mất và bạn thực sự cần một cái gì đó hiệu quả hơn.