Chociaż można śmiało powiedzieć, że XML jest gadatliwy, należy go uspokoić, mając świadomość, że ta gadatliwość nie jest „narzutem” w stosunku do treści, ponieważ zawiera semantykę; narzut jest symptomatyczny dla każdego protokołu, który podkreśla dynamikę w przeciwieństwie do struktury statycznej. Na przykład HTML jest tak naprawdę zrelaksowaną formą XML, która przekazuje treść o dynamicznej strukturze, która może być uważana za aspekt zawartości. Możesz odróżnić zawartość tabeli od samej tabeli, ale fakt, że treść jest danymi tabelarycznymi o określonych relacjach, jest integralną częścią treści; gdybym po prostu wziął każdą komórkę i przesłał to wszystko jako jeden długi ciąg, struktura i te relacje zniknęłyby, a więc straciłem informacje i czy to nie treść?
Rozważmy 8-bajtową wiadomość, która może stanowić dane tabluar. Jeśli używam bardzo statycznego protokołu, mógłbym minimalnie przesłać go bez dodatkowych kosztów ogólnych, po prostu definiując taki protokół:
- Każda wiadomość ma dokładnie 8 bajtów, więc nie musimy podawać długości ani zawierać żadnej sekwencji kończącej.
- Osiem bajtów zawsze odnosi się do siatki 2 x 2, w której każda komórka zawiera wartość 16-bitową.
Jeśli wszystkie moje wiadomości są dokładnie takie, używanie XML, HTML lub XMPP może być uważane za głupie - tracę przepustowość na komponenty strukturalne, które są zawsze takie same i z góry określone, i marnuję odpowiedni czas obliczeń na obu końcach, tworząc go i analizując. Minimalna, właściwa strona HTML, która zawiera tylko tabelę 2 x 2 z kilkoma znakami w każdej komórce, prawdopodobnie będzie miała co najmniej 100 bajtów, aby pomieścić koszty związane z formatowaniem i protokołem.
Jeśli jednak nie wszystkie moje wiadomości są dokładnie takie, to określenie, jaki to rodzaj wiadomości, może nie być dosłowną częścią „ładunku”, ale jest niezbędnym komponentem pod względem treści. Mógłbym to zrobić za pomocą zaledwie dwóch dodatkowych bajtów i wprowadzić znacznie większą dynamikę:
- Wiadomości mają teraz zmienną długość, 0–255 bajtów, a pierwszy bajt wskazuje długość.
- Istnieje (do) 256 kodów dla różnych predefiniowanych typów wiadomości, z których jeden to „tablica 2 x 2”, czyli drugi bajt.
Teraz moje 8 bajtów zawartości tabeli wymaga 2 bajtów narzutu, ale istnieje znacznie szerszy zakres możliwości w zakresie tego, jakie rodzaje wiadomości mogą być wysyłane za pomocą tego niestandardowego protokołu.
Nadal nie jest blisko możliwości strony HTML lub specyfikacji przestrzeni nazw XML (lub ich zestawu, którym w istocie jest XMPP ).
Na tej podstawie, jeśli przeważnie wysyłasz proste 8-bajtowe wiadomości, XMPP prawdopodobnie przesadza. Jednak niekoniecznie tak bardzo. Twierdzenie, że „pojedyncza wymiana żądania / odpowiedzi w celu przesłania jednego bajtu danych z URZĄDZENIA PODŁĄCZONEGO IOT do serwera ma więcej niż 0,5 kB”, wydaje mi się, patrząc na odpowiedni RFC , potencjalną przesadę (ale nb, wszystkie Rzuciłem okiem na to, nigdy nie wdrożyłem ani nie używałem XMPP). Nie wątpię, że mógłbyś skonstruować taki przykład, ale prawdopodobnie nie jest to minimalny przykład.
Ponieważ protokół jest zorientowany na TCP, ustanowienie „strumienia XML zakwalifikowanego przez przestrzeń nazw„ jabber: client ”- należy traktować jako część wiadomości tylko wtedy, gdy wykonujemy jedną rzecz - urządzenie kontaktuje się z serwerem, aby wysłać 8 bajtów, wysyła dane rozłączają się. Jeśli relacja jest bardziej trwała, co często bywało w kontekście Internetu Rzeczy, możemy założyć, że urządzenie ma już ustanowione połączenie z miejscem docelowym. W takim przypadku, jeśli ostatecznym miejscem docelowym wiadomości jest serwer (w przeciwieństwie do innego klienta, serwer przekaże wiadomość), wówczas obciążenie protokołu jest potencjalnie minimalne.
<message><body>8 bytes.</body></message>
Mizerne 33 bajty „narzutu”. Warto tutaj zaznaczyć, że XML jest tekstem, więc jeśli twoje wiadomości są często binarne, stanie się o wiele mniej odpowiednie, ponieważ dane muszą zostać zakodowane (np. Base64 ), co powoduje dodatkowe obciążenie i obliczenia wymagania
Ostatecznie:
Czy XMPP ma duży narzut związany z urządzeniami IoT wysyłającymi krótkie, częste wiadomości?
Jeśli istnieje trwałe połączenie, a wiadomości są w dużej mierze nieustrukturyzowane, nie sądzę. Jeśli jednak nie potrzebujesz tego, co oferuje (dynamizm w odniesieniu do struktury), prawdopodobnie są bardziej odpowiednie metody.
Kontynuujmy to, jeśli mamy kontekst, w którym pojedynczy serwer centralny przetwarza i / lub polega na komunikatach między różnymi urządzeniami, nawet jeśli to, co robi jedno z tych urządzeń, może być zawsze proste i jednoznaczne, protokół, który może zawierać różnorodne wiadomości byłyby nadal przydatne. Jeśli urządzenie klienckie ma ograniczone zasoby, możemy na stałe zakodować większą część protokołu, a zawijanie każdej wiadomości z tego końca staje się bardzo prostym zadaniem; Wierzę, że robi to wiele urządzeń IoT, które wdrażają serwery HTTP (co jest odwrotnością „prostych klientów, złożonego serwera”). Serwery te nie są w stanie obsłużyć żadnego rodzaju żądania HTTP (z wyjątkiem wstępnie sformatowanego odrzucenia) i mają bardzo dobrze zdefiniowany, skoncentrowany zestaw rzeczy do zrobienia i odpowiedzi, które wyślą, ale ponieważ mimo to działają poprawnie jako serwery HTTP,