XMPP'nin kısa, sık mesajlar gönderen IoT cihazları için büyük bir yükü var mı?


10

IoT cihazları için potansiyel bir iletişim protokolü olarak XMPP hakkında okuyordum, ancak bir kaynağı okuduktan sonra, her mesaj için ek yükten endişe ediyorsanız gerçekten uygun bir protokol olup olmadığından emin değilim.

Bu kaynak şunları belirtir:

Bununla birlikte, XMPP'nin EMBEDDED IOT PROTOCOLS için bir şekilde istenmeyen olmasını sağlayan bir takım problemleri vardır. XML tabanlı bir protokol olarak, XMPP HTTP'den çok daha ayrıntılıdır ve ağır veri yükü vardır. IOT BAĞLANTILI BİR CİHAZ'dan sunucuya bir bayt veri göndermek için tek bir istek / yanıt değişimi 0,5 kB'den fazladır.

Verimli XML Değişimi (EXI) adı verilen bir XML kodlaması kullanarak XMPP'yi sıkıştıracak bir taslak belirtim vardır. Ancak EXI ile bile, aynı bir bayt veri sadece XMPP'den yüzlerce bayt protokol yükü alır. EXI'nin işlenmesi, diğer seçeneklerden daha zor. Bu doğal sorunlar nedeniyle, gömülü IoT uygulamalarında genellikle XMPP kullanmaktan kaçınılması önerilir.

Bununla birlikte, XMPP kendisini IoT uygulamaları için uygun olarak tanıtmaktadır (özellikle düşük ek yükü olduğunu söylemese de), bu nedenle böyle büyük, görünüşte ayrıntılı bir protokolün IoT cihazları için önerilmesi / tanıtılması tuhaf görünmektedir.

XMPP'nin yükü, kaynağın az miktarda veri için önerdiği kadar büyük mü? Örneğin, 8 baytlık bir mesaj gönderirken ne kadar ek yük olurdu?

Ayrıca, EXI sıkıştırması kullanıldığında (kaynakta belirtildiği gibi) ek yük çok mu büyük ? Bu da bazı tuzaklar ile gelir mi?


4
İlginç soru. XMPP hakkında bilgi sahibi olmamakla birlikte, EXI'nin her iki uç noktasının senkronize edilerek yapılması gereken bir şemaya sahip olması gerektiğini belirtmek önemlidir. Ayrıca IoT cihazı, 8 baytlık mesajlar göndermek için çok karmaşık görünen bu xml'yi deşifre etmeli / çözmelidir.
Helmar

1
@Helmar, XMPP ile paket boyutunda kazandığınız gibi görünüyor, hesaplama karmaşıklığında kaybediyorsunuz.
Aurora0001

1
Bu sorunun genellikle iyi olduğunu düşünüyorum ancak: "Örneğin, her 2 dakikada bir 8 baytlık ileti gönderirken ne kadar ek yük olurdu?" -> "İki dakika" teğettir ve önde gelen şeylere yol açmaya eğilimlidir. Gerçekten sorduğunuz şey, 8 baytlık bir mesajın ne kadar yükü olacağıdır (sadece bir veri parçasıysa, 1 baytlık mesajla aynıdır). Bir zaman bileşeniyle ilgili olarak, bu sadece bant genişliğine ve ölü basit matematik olması gereken bir ağ protokolünün kullanımını düşünen herkes için bağlıdır .
goldilocks

1
@delicateLatticeworkFever Eğer alakalı olduğunu düşünmüyorsanız onu düzenleyeceğim (tamamen ikna olmadım ama daha fazla detayın daha az olduğunu düşündüm)
Aurora0001

2
Bu bir öneri, evet. Sadece "Tamamen belirtilmemiş bir cihazın belirli sayıda bayt göndermesinin ne kadar sürdüğüne bağlı değil mi?" Örneğin, yanıt ~ 0.5 kB ise, birimlerde zaman unsuru yoktur;) Bu belirtilmemiş cihazın bant genişliğindedir.
goldilocks

Yanıtlar:


8

XML'in ayrıntılı olduğunu söylemek adil olmakla birlikte, bu anlamın anlambilimi kapsadığı için içerikle ilgili olarak tümüyle "yük" olmadığının bilincinde olmalıdır; statik yapının aksine bir dinamiği vurgulayan herhangi bir protokolün belirtisidir. Örneğin, HTML gerçekten içeriği dinamik bir yapıya, içeriğin bir yönü olarak kabul edilebilecek bir yapıya taşıyan rahat bir XML biçimidir. Bir tablonun içeriğini tablonun kendisinden ayırabilirsiniz, ancak içeriğin belirli ilişkilere sahip tablo şeklinde veriler olması, içeriğin ayrılmaz bir parçasıdır; eğer her bir hücreyi alıp hepsini uzun bir dize olarak aktarırsam, o yapı ve bu ilişkiler ortadan kalkar ve bu yüzden bilgi kaybettim ve bu içerik değil mi?

Bazı tabluar verileri oluşturabilecek 8 baytlık bir mesajı ele alalım. Çok statik bir protokol kullanırsanız, en azından ek bir ek yük olmadan sadece böyle bir protokol tanımlayarak iletebilir:

  • Her mesaj tam olarak 8 bayttır, bu nedenle uzunluğu belirtmemize veya herhangi bir sonlandırma dizisi eklememize gerek yoktur.
  • Sekiz bayt her zaman, her bir hücrenin 16 bitlik bir değer içerdiği 2x2 ızgaraya başvurmak için alınır.

Tüm iletilerim tam olarak böyle ise, XML, HTML veya XMPP kullanmak aptalca sayılabilir - Her zaman aynı ve önceden belirlenmiş yapısal bileşenler üzerinde bant genişliği harcıyorum ve her iki uçta da karşılık gelen hesaplama zamanını boşa harcıyorum. Her hücrede birkaç karakter içeren 2 x 2 tablo içeren minimal, uygun bir HTML sayfası, biçimlendirme ve protokol yükünü karşılamak için muhtemelen en az 100 bayt olacaktır.

Ancak, tüm iletilerim tam olarak bu değilse, ne tür bir ileti olduğunu belirtmek, "yararlı yük" ün gerçek bir parçası olmayabilir, ancak içerik açısından gerekli bir bileşendir. Bunu sadece iki baytla yapabilir ve çok daha fazla dinamizm getirebilirim:

  • İletiler artık değişken uzunluktadır, 0-255 bayt ve ilk bayt uzunluğu belirtir.
  • Önceden tanımlanmış farklı mesaj türleri için 256 kod vardır, bunlardan biri "2x2 tablo" dır, bu ikinci bayttır.

Şimdi 8 bayt tablo içeriğim 2 bayt ek yük gerektiriyor, ancak bu özel protokolle ne tür mesajların gönderilebileceği konusunda çok daha geniş olasılıklar var.

Hala bir HTML sayfasının veya XML ad alanı belirtiminin (veya XMPP'nin esasen ne olduğu ) bir kümesinin olanaklarına yakın değil .

Buna dayanarak, çoğunlukla yaptığınız şey basit 8 baytlık mesajlar gönderiyorsa, XMPP muhtemelen aşırıya kaçıyor. Ancak, o kadar da değil. İlgili RFC'ye bakarak, potansiyel bir abartı (ama nb, hepsi), bana "IOT BAĞLANTILI BİR CİHAZIN sunucuya bir bayt veri göndermek için tek bir istek / yanıt değişimi" 0.5 kB'den fazla olduğu iddiası gibi görünüyor. Yaptığım bir bakış, hiç XMPP kullanmadım veya kullanmadım). Böyle bir örnek oluşturabileceğinizden şüphem yok, ama bu muhtemelen minimal bir örnek değil .

Protokol TCP yönelimli olduğundan, "'jabber: client' ad alanı" tarafından nitelenen bir XML akışı oluşturmak yalnızca iletinin bir parçası olarak kabul edilirse iletinin bir parçası olarak düşünülür - cihaz 8 bayt göndermek için bir sunucu ile iletişim kurar, gönderir veri, bağlantıyı keser. İlişki daha sık devam ederse, bu genellikle bir IoT bağlamında olur, o zaman cihazın zaten hedefe kurulmuş bir bağlantısı olduğunu varsayabiliriz. Bu durumda, iletinin nihai hedefi sunucu ise (sunucu başka bir istemcinin aksine iletiyi iletecek), bu durumda protokol yükü potansiyel olarak minimumdur.

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

33 baytlık "tepegöz". Burada XML'nin metin olduğunu belirtmek gerekir ve bu nedenle mesajlarınız genellikle ikili ise, o zaman çok daha az uygun hale gelecektir, çünkü verilerin daha fazla ek yük ve hesaplama eklenmesi için kodlanması (örn. Base64 ) gerekir. Gereksinimler.

Sonuçta:

XMPP'nin kısa, sık mesajlar gönderen IoT cihazları için büyük bir yükü var mı?

Kalıcı bir bağlantı varsa ve mesajlar büyük ölçüde yapılandırılmamışsa, sanmıyorum. Bununla birlikte, sunduğu şeylere (yapıya ilişkin dinamizm) ihtiyacınız yoksa, muhtemelen daha uygun metodolojiler vardır.

Bunu takip ederek, tek bir merkezi sunucunun çeşitli cihazlar arasında mesajları işlediği ve / veya güvendiği bir içeriğimiz varsa, bu cihazlardan herhangi birinin yaptığı her zaman basit ve anlaşılır olsa da, çeşitli mesajlar hala faydalı olacaktır. İstemci aygıtta sınırlı kaynaklar varsa, protokolün çoğunu sabit olarak kodlayabiliriz ve her iletiyi bu uçtan sarmak çok basit bir iş haline gelir; HTTP sunucularını dağıtan birçok IoT cihazının ("basit istemciler, karmaşık sunucu" nun tersi) bunu yaptığına inanıyorum. Bu sunucular herhangi bir HTTP isteğini işleyemez (önceden biçimlendirilmiş reddetme hariç) ve çok iyi tanımlanmış, bir şeylerin yapacakları ve gönderecekleri yanıtlara sahip olurlar, ancak HTTP sunucuları olarak sorunsuz çalıştıklarından,


3

Her şeyden önce, XML'nin gerçek zamanlı mesajları bir miktar başarı ile kapsüllemek için kullanıldığını ve özellikle IM ve XMPP'de iletişim kurmak için büyük ölçekte kullanıldığını söylemeliyim. Ayrıca, bu veri sunum sistemi için başka bir uygulama alanı bulmaya çalışmak için XML bilgisinden faydalanmak isteyen bazı şirketler var gibi görünüyor.

Ancak, herkes XML'in mesajlaşma sistemlerindeki her şeyin cevabı olduğuna ikna olmamıştır. Örneğin, son yıllarda JSON'u XML yerine verileri serileştirmenin bir yolu olarak kullanan çevrimiçi sistemlere kayda değer bir değişim oldu ve geliştirici şapkamı bir anlığına takarsam, yerel kodlama / kod çözme araçlarının yerel temsili (örneğin Python, PHP, Javascript'te), XML'nin bu cevapları doğru şekilde almak için daha fazla zamanı olsa bile, XML için olanlara kıyasla JSON için olduğundan çok daha kolay görünüyor.

XML, nispeten karmaşık bir metin ayrıştırıcısına ihtiyaç duyduğundan, bilgisayarların işlenmesi zor bir temsildir ve daha sonra, verilerin bir programda çıkarılmasına izin vermek için bir tür hiyerarşik temsildir. Çok fazla metin bulunduğundan, kodlama / kod çözme için oldukça fazla belleğe ihtiyacınız vardır.

Genellikle XML'in verilerin temsiline çok değer kattığı belirsizdir: çekirdek mesaj derinden hiyerarşik değilse, çok fazla metin samanı eklemek gereksiz gibi görünür, ancak paradoksal olarak mesajın kodunu çözerseniz metinsel temsili zor bir iş olacak ve çok fazla kaynağa ihtiyaç duyacak. Ayrıca, metinde temsil etmenin faydası benim için net değil: İletişim sistemlerini ilk kez yazıp hata ayıkladığımızda, neyin yanlış gittiğini anlamamıza yardımcı olmak için izleme / kod çözme araçlarını (örneğin Wireshark) kullanmak yaygındır. Uzun vadede, her şey iyi çalışıyor ve hiçbir insanın ileri geri giden mesajlara (sadece bilgisayarlar) ayrıntılı olarak bakması gerekmeyecek. Bilgisayarlar ikili temsili tercih ederler. Metinsel temsil, konuşlandırmanın herhangi bir aşamasında yer alan hiç kimseye fayda sağlamaz.

XML, aynı zamanda bilgisayarlar için zor bir işken, insanların okuması (ve manuel olarak oluşturması) zordur; Dolayısıyla ne bilgisayarlar için ne de insanlar için uygun bir sistemdir.

Önemlisi, IoT'nin verimli olmasını arzu eden bazı özel kısıtlamaları var. IoT cihazları tipik olarak sınırlı işleme gücüne ve depolamaya sahip olacaktır (genellikle büyük ölçekli ikincil depolama alanı yoktur, sadece bazı RAM ve EEPROM). Bir IoT cihazı mümkün olan en basit iletişim bağlantılarına sahip olabilir, hatta bir TCP / IP yığını bile olmayabilir. Standart bir işletim sisteminin (örneğin Linux, Android) kullanımda olduğu karmaşıklık düzeyinde bile çok çeşitli mikrodenetleyici tasarımları olacaktır; bu, kullanımı kolay XML arayüzleri sunarak piyasaya sürülecek hazır araçların sayısını sınırlar.

Özetle, IoT ile, donanım kısıtlamalarına, iletişim tarzına (örneğin yayın, datagram, güvenilir vb.), İletişim sıklığına vb. Bağlı olarak veri sunumunun durum bazında daha iyi kaldığından şüpheleniyorum. XML kesinlikle IoT'nin olmazsa olmaz koşulu olarak düşünülmemelidir .


3
  1. Yıllar önce kullanmanın farkını analiz ettim

    Geleneksel ile karşılaştırmalı olarak ödeme işlemi gösterimi için ödeme ağındaki XML (kart_sayısı, tarih, saat, terminal_kimliği ve ek öğeler listesi)

    bit eşlemli ISO8583

  2. XML'in ek yükü vardır. Her biri merkezi ana bilgisayara saatlik / günlük 10+ ileti gönderen 10000+ düğümü olan ağlarda etkiyi düşünüyorsanız, XML söner ve gerçekten daha verimli bir şeye ihtiyacınız vardır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.