Hücresel Ağ Odaklı IoT Protokolleri için hangi Mesajlaşma Türü kullanılabilir?

Son zamanlarda Youtube'da inanılmaz bir video bulduğumda dikkatimi çekti:

Micheal E. Anderson: IoT, OpenIoTSummit, Linux Vakfı için Mesajlaşma Tekniklerinin Karşılaştırılması .

Konuşması için slaytlar burada mevcuttur

Videonun 26 ve 41. Slaytlarında şu konu hakkında tartışıyor (nasıl yorumlayayım):

Hücresel operatörler, IoT tüketicilerinin daha fazla Veri tükettiklerinden HTML , XML veya JSON türü iletiler kullanmasını tercih eder . Daha Fazla Veri, tüketicilere hizmet için daha fazla para talep edebilecekleri anlamına gelir.

Ben bir çok özel protokol viz anlıyorum. SigFox , Kablosuz HART veya Z Dalgası daha düşük veri hızlarına sahiptir ve bu tür taşıyıcılar üzerinde büyük veri göndermek pahalı bir olay olabilir.

Soru

• Mevcut ve gelecekteki IoT tüketicileri için uygun maliyetli çözümler haline getiren Özel Protokollerde kullanım için kullanılan başka hafif mesajlaşma formatları var mı? (Karanlıkta çekim: Hafif XML veya HTML veya JSON denilen bir format bir yerde mi uzanıyor?)

• CBOR gibi bir şey belki de kullanılmış olabilir mi?

Protokol veya mesaj formatını mı soruyorsunuz ? Verilerin formatını kastederken genellikle protokol terimini yanlış kullanırız. Bunu kendim yaparım, çünkü ayrım herkes için açık değildir.

IoT'de kullanılan mesajlaşma protokolleri, en azından http'den çok daha kompakttır ve mesajlaşmada önemli olan önemli özellikler sunar (oturumlar, akış kontrolü, güvenilirlik, vb.). İleti biçimi, iletideki gönderilen verilerdir. Sorduğun şey bu.

En kompakt mesaj formatı, dikkatle düşünülmüş elle döndürülmüş bir ikili formattır. Düşük bant genişliği senaryolarında, birkaç bayt göndermek istediğinizde ve bu baytların tam olarak neye benzediğini bilmek istediğinizde sıklıkla kullanılır. Daha büyük mesajlar için dezavantajlar önemlidir ve genel olarak her ne pahasına olursa olsun önlenmelidir.

Birçok farklı veri serileştirme seçeneği hakkında ayrıntılı bir değerlendirme yaptım. Protobuf, mesaj paketinin oldukça kompakt olmasını bekledim. Ancak, ikinci sorunum, cihazdaki C dahil olmak üzere bir dizi farklı platformda bulunan ve mevcut olan kütüphaneleri bulmaktı.

Yerleştirdiğim biçim, şaşırtıcı bir şekilde, gzip sıkıştırılmış JSON idi. Uygulamak ve anlamak kolaydır, her yerde çalışır ve kullandığım verilerle diğer yöntemlerle neredeyse aynı veya daha küçüktü.

TLS gibi güvenli bir kanalınız varsa, yine de TLS el sıkışmalarında bir yığın veri (> 6KB) tüketeceğinize dikkat edin.

Birkaç yıl önce, protokol arabellekleri gibi bir formata hakim olmayı bekledim, ama pek bir şey olmadı. Muhtemelen json'un yazılması ve ayrıştırılması (ve sıkıştırılması) kolaylığı nedeniyle. Flatbuffers'ın görünümünü seviyorum , ancak avantaj, ayrıştırma hızında kompakt olmaktan çok daha fazlası.

Soruşturma aşamasında olduğunuz için, durumunuza özgü verileri kullanarak her birine biraz kod yazmanızı ve bazı karşılaştırmalar yapmanızı öneririm. Başlarken sert verilere sahip olmak seçimlerinizi onaylamanıza yardımcı olur.

İşaretleme tabanlı bir biçimin en büyük avantajı, ilettiğiniz verilerin seçiminde esnekliği korumanızdır. Bu, birkaç yıllık gelişim boyunca gelişen bir hizmet öngördüğünüz, gelişen bir ekosistemde büyük önem taşımaktadır.

Sıkı kodlanmış bir ikili veri yapısı iletimde etkili olsa da, yapının nasıl görüneceğine en azından karar vermeniz gerekir. Daha sonra, bir alanın bile genişlemeye ihtiyacı olduğunu fark ettiğinizde, sıkışıp kalırsınız. Protokolde bir güncelleme yapmak bile zordur, çünkü her uç nokta güncellenene kadar eski bir kodlamayı geçersiz kılamazsınız.

Bu, optimum yaklaşımın minimalist paketleri ve işaretleme tabanlı kodlamayı (ikincisini yedek olarak kullanmak) karıştırmak olduğunu göstermektedir. Bunun değeri en yüksek bant genişliği faydalı yüklerine bağlıdır. Sık sık video boyutunda yığınlar aktarıyorsanız, nadir kontrol verilerini optimize etmek daha az değerlidir. Sık sık küçük transferleriniz varsa (sıcaklık olabilir), iletimdeki ek yükü en aza indirgemek mantıklıdır - ancak belki de transferleri toplu yapmak da iyidir.