IoT Uygulaması için uygun protokolü seçme

İşyerinde Şey / Kısıtlı Cihazın GPS konumunu belirli bir sunucuya düzenli aralıklarla gönderdiği bir IoT senaryomuz var. Kısıtlı cihaz, bataryayla çalışan ve bağlantı için bir GSM / SIM kalkanı kullanan Arduino benzeri bir karttır. Bunlar bizim tasarım hedeflerimiz:

• Pil ömrünü en üst düzeye çıkarma
• Veri aktarımını en aza indirme

Test amacıyla, 500 bayt civarında mesajlarla sonuçlanan HTTP'yi kullandık, ancak veri iletimi için daha uygun bir protokol kullanmanın zamanı geldi. Veri aktarımının bazı özellikleri şunlardır:

• Yük normalde oldukça küçüktür az 50 bayttan (oldukça uzak tipik MTU değerleri dan, yani her şey bir IP paketinde sığmalı)
• Veriler yaklaşık olarak dakikada bir gönderilmelidir . Bazı sapmalar kritik değildir.
• Öyle bazı mesajlar kaybetmek için OK
• Şu anda, cihazın servis r'den herhangi bir cevaba ihtiyacı yoktur (ancak, bu gelecekte değişebilir). Sunucunun aygıtlarla herhangi bir görüşme başlatması da gerekmez .

Şimdiye kadar şu olasılıkları düşündük:

• TCP üzerinden özel protokol . Bu, iletiyi 10 kat daha küçük yapan HTTP başlıklarından kurtulacaktır. Bu bizim güvenilir / muhafazakar yaklaşımımızdır.
• UDP üzerinden özel protokol . UDP'nin daha küçük başlıkları olduğundan ve güvenilirlik için ek yükü olmadığından, oldukça verimli olmayı umuyoruz. Yorumlandığı gibi, burada bir mesaj kaybetmek ya da bir endişe yoktur ... ancak, farkında olmadığımız güvenilirlikle ilgili başka sorunlar olabilir.
• MQTT (TCP üzerinden standart): TCP'ye kıyasla neredeyse hiç ek yük olmadan, bu da bir seçenek olabilir ... Ancak, GSM / SIM teknolojisi ile çok fazla deneyime sahip değiliz ve nasıl olduğunu bilmiyoruz sürekli bir MQTT bağlantısı bu şekilde çalışır ve bağlantı kalp atışı bant genişliğinin böyle düşük frekanslı bir veri aktarımı için değer olup olmadığı.
• CoAP (UDP üzerinde standart): Umut verici görünüyor. Üstbilgiler için sadece 4 bayt ek yük ve UDP üzerinde çalışıyor. Ancak bilinmeyen UDP riskleri var.

Herkes bir ipucu verebilir mi? Şimdiden teşekkürler.

TCP, UDP ve MQTT ile ilgili deneyimlerimin yanı sıra gözden geçirilecek bazı ek kaynaklar hakkında birkaç düşünce.

UDP ile, bir ağ düğümü, istemci üzerindeki bir uygulamanın gönderilen UDP mesajlarının yalnızca bazılarını gördüğü sessiz hata sorunuyla karşılaştım. Ağ trafiğinin ters gitmesinin çok fazla nedeni vardır. UDP'nin sorunu, paket üreticisi ve paket tüketicisi arasındaki ağ yolundaki düğümlerden herhangi biri olduğunda paketlerin hemen hemen atılabilmesidir. Wikipedia konusuna bakın Paket kaybı .

Soru, mevcut ağ bağlamında ne olursa olsun kayıp oranınızdır. Bu bir LAN veya alt ağ içindeki iletişim ise kayıp oranınız düşük olabilir. WAN'da veya internette kayıp oranınız oldukça yüksek olabilir. UDP paketleri birkaç nedenden dolayı atılır ve yönlendirilir, ancak ağ koşulları bu atlama sayısının azaltılmasına izin verir. Hesap verebilirlik olmadan paketleri büyük boşluğa göndermek sessiz arıza olasılığını açık bırakır.

Durumunuzda, bir ack almadan zaman aşımından sonra yeniden iletim ile basit bir ack yeterli olacaktır.

Bakımlı bir TCP bağlantısı üzerinden XML mesajları yaptım ve harika çalıştı. Ben işlemek için uygulama katmanına her arabellek tam iletileri teslim bir katman vardı. İletinin başlangıcında XML başlangıç ​​etiketi ve iletinin tamamının ne zaman alındığını bilmek için bir XML bitiş etiketi ile paketlemek için XML kullandım.

TCP'nin sıralı paket sırası, tekrarsızlık ve bağlı bir aktarım mekanizması olması gibi birkaç özelliği vardır, diğer ucun kaybolup kaybolmadığını bilmeniz biraz zaman alabilir. Bağlanmak ve bağlantıyı kesmek gecikmelere neden olabilir, ancak normal koşullar altında külfetli olmaz, ancak ağ koşulları TCP veriminin yavaşlamasına neden olabilir.

MQTT, normalde TCP olan bir ağ aktarım katmanı tarafından aktarılan bir protokoldür. MQTT bir yayınlama / abone olma modeli kullanır, bu nedenle mesaj depolaması olmaz. Dolayısıyla, bir yayıncı abone bağlı değilse o zaman bağlandığında bir mesaj yayınladığında, mesajı görmez. MQTT neredeyse gerçek zamanlı, sanırım kısaltmanın telemetri kısmı bu kadar. Ben küçük mesajlar için MQTT gibi ve Mosquitto kullanarak MQTT üzerinden JSON yük ile bazı deneyler yapıyorum. Bu makaleye , MQTT ve hizmet kalitesi hakkında genel bilgi veren Mosquitto (MQTT) ile güvenilir mesaj teslimi . Ve örnek bir uygulama olan IoT - MQTT Yayınlama ve Abone C Kodu da dahil olmak üzere kaynaklara bağlantılar içeren bu kısa makaleye bakın .

Mesajları saklamak için abone içinde JSON metni ve bir SQLite3 veritabanı kullanarak MQTT ile yaptığım deneyimler https://github.com/RichardChambers/raspberrypi/tree/master/mqtt adresinde kaynak C'de ve oldukça dağınık olsa da.

İşte 13 dakikalık bir video # 144 İnternet Protokolü: CoAP vs MQTT, Ağ Koklama ve IKEA Tradfri Hacking için hazırlık . Bu, CoAP, Kısıtlı Uygulama Protokolü hakkında ilginç bir makale : CoAP, IoT'nin 'modern' protokolüdür . CoAP'ın bu toplamı var:

Erken benimseyenler, Kısıtlı Uygulama Protokolünün kısıtlı ağlar ve cihazlar için son derece iyi çalıştığını kabul eder. Bilinmeyen bir şey: "Çok sıkışık bir kablosuz ağda - Wi-Fi veya hücresel - CoAP, MQTT gibi bir İletim Kontrol Protokolü tabanlı (TCP) protokolünün bir el sıkışma işlemini bile başaramadığı durumlarda çalışmaya devam edebilir, "Vermillard dedi.

Bunun nedeni, diğer IoT protokollerinin çoğunun aksine, CoAP'nin UDP üzerine inşa edilmiş olmasıdır. Başka bir deyişle, TCP ile karşılaşıldığı şekliyle protokol el sıkışması veya hata düzeltme anlamına gelmez. "CoAP, HTTP kadar güvenilir olmayabilir veya MQTT gibi iletilerin teslim edilmesini garanti etmez, ancak son derece hızlıdır." "Bazı mesajların alınamaması sorununu yaşıyorsa, aynı zaman aralığında daha fazla mesaj gönderebilirsiniz."

Bakabileceğiniz AMQP, STOMP ve CBOR gibi birkaç tane daha var. Bkz CBOR standart bir web sitesi gibi bu tez, CBOR protokolü Uygulanmasına ve değerlendirilmesi . Mesajlaşma Protokolünüzü Seçme: AMQP, MQTT ve STOMP'yi karşılaştıran ve kontrast oluşturan ve RabitMQ aracısı hakkında bir notla biten AMQP, MQTT veya STOMP makalesine bakın :

Umarım bu, birçok kullanım vakanız için orada protokol çorbasında gezinmeye başlamanıza yardımcı olabilir. Şirketlerin farklı ihtiyaçları olan birçok uygulamaya sahip olması yaygın olduğundan, farklı uygulamalarda üç brokerın hepsine de ihtiyaç duyabilirsiniz. Burası, RabbitMQ gibi katı bir çok protokollü, çok dilli brokerın devreye girdiği yerdir - çünkü STOMP, MQTT veya AMQP'yi içeri gönderebilir ve diğerlerinden birini çıkarabilir. Bu protokollerden biri tarafından kilitlenmenize gerek yoktur - her üçü de RabbitMQ aracısı tarafından desteklenir ve bu da onu uygulamalar arasında birlikte çalışabilirlik için ideal bir seçenek haline getirir. Eklenti mimarisi ayrıca RabbitMQ'nun gelecekte bu protokollerin ek veya güncellenmiş sürümlerini desteklemek için gelişmesini sağlar.

Yaklaşık 60 slayttan oluşan bu slayt paylaşım paketi, güvenilirlik ve sağlamlık için farklı ihtiyaçlara sahip olan iki farklı IoT grubunun (Tüketiciler ve Endüstriyel) gereksinimlerine bakan dört farklı IoT protokolü arasında bir karşılaştırma ve kontrast yapar. IoT için Doğru Mesajlaşma Standardı nedir? .

UDP için mükemmel bir uygulama gibi geliyor: istemci-sunucu topolojisi (pub / sub gerekli değil), paket kaybına toleranslı ve tek paket iletimleri arasındaki büyük boşluklar, sipariş dışı varışın sorun olmadığı anlamına gelir.

Bağlantı kurma ve paket yükü tasarrufları sizin lehinize olacaktır.

Sadece sessiz hata sorununa karşı hafifletmeniz gerekir. Bunu yapmanın pek çok yolu var ama benim önerim sunucunun her x (örneğin 10) paket aldığında yanıt vermesini sağlamak. Bu şekilde müşteri, paketlerinin kaç tanesinin geçmekte olduğunu bilir ve bir eşiğin altındaysa, paket kaybına karşı iletim sıklığını artırabilir. Hiçbir şey geçmezse, TCP yine de yardımcı olmaz, bu yüzden durum ortadan kalkana kadar istemciyi sıkıntı moduna sokmanız daha iyi olur.

İnternet üzerinden UDP paket kaybı genellikle yüksek değildir ve bu genellikle geçici bir fenomendir. GSM bazı tamponlama ve radyo sinyal değerlendirmesi sağlar, bu nedenle sahte gürültüye bir miktar tolerans sağlar.

Harici olarak GSM / SIM kullanmak zorunda mısınız?

Bir alternatif, aşağıdakileri içeren bir LoRa ağı kullanmak olabilir:

• küçük taşıma yükleri için son derece optimize edilmiştir
• minimum enerji kullanımı için tasarlanmıştır (ve bu nedenle maksimum pil ömrü)
• tasarım ile uzun menzilli
• bağlantı sınıfları var (her zaman açık, onaylanmış, onaylanmamış)
• planlanmış indirme pencereleri (ör. ürün yazılımı güncellemeleri veya RX ACK'lar için)

Çoğu ülkede mevcut topluluk veya ticari LoRa altyapısına bağlanabilir veya daha uygunsa kendi LoRa hub'larınızı dağıtabilirsiniz.

Dünya çapında aktif bir gelişme var ve prototip kalkanlarının (örneğin Arduino için) kolay bulunabilirliği var.

JSON verileriyle minimum bir HTTP yanıtı tercih ederim ... HTTP yanıtı 500 baytlık HTTP aktarımının çok altında olabilir ve RESTful web uygulamaları için birçok istemciyle uyumluluğunuz devam eder.

Yaklaşık 130 baytlık HTTP verisi olan minimum bir HTTP mesajı (örn. JSON sonucu ile) şöyle görünür:

HTTP/1.1 200 OK
Server: ProprietaryAndroid
Connection: close
Content-Type: application/json
{
  "lat": "42.00000",
  "long": "10.00000"
}

yalnızca uygulamanızdan sunucuya veri göndermek istiyorsanız, URL parametresini enlem / boylam olarak ayarladığınız bir HTTP GET'i kullanabilirsiniz. İstekte yanıttan daha az veri var.

GET /?lat=42.00000&long=10.0000 HTTP/1.1
Host: 192.168.0.2 
User-Agent: Proprietary
Accept: */* 
Connection: close

"En iyi" protokol yoktur. Dikkate alınacak çok sayıda değiş tokuş:

• Cihazlarınız rastgele bağlantı noktaları engellenmiş rastgele ağlarda olacak mı? Öyleyse, HTTPS kullanmak daha iyi olabilir.

• UDP gönderirseniz, her seferinde son N ölçümlerini her zaman gönderebilirsiniz, böylece küçük paket kaybı yok sayılır. UDP'yi güvenilir bir protokole dönüştürerek bir ACK paketleri de gönderebilirsiniz. (UDP'nin üstündeki çoğu protokol bunu yapar.)

• Müşterileriniz verilerinin şifrelenmemiş olarak görünmesine dikkat eder mi? Bilgisayar korsanlarının şifrelenmemiş bu bağlantılara kötü veri enjekte edip edemeyeceğini müşterileriniz önemseyecek mi? (Öyleyse, şifreleme isteyebilirsiniz.)

• Birisi protokolünüzü koklar ve verileri değiştirirse ne olur? Bir cihazın başka bir cihazın verilerinin üzerine yazmasını engelleyebilir misiniz?

• En fazla kaç cihaza sahip olacaksınız? Tüm bu cihazlarla nasıl başa çıkacaksınız? Verileri gitmesi gereken yere nasıl yönlendireceksiniz? Sunucu altyapınızın bakımı ve yükseltmeleri ile nasıl başa çıkıyorsunuz? Deneyiminiz yoksa, muhtemelen birçok eşzamanlı bağlantıyı yönetme yeteneğinizi aşırı tahmin edersiniz. Bir satıcıya dış kaynak kullanmak (ve AWS IoT gibi protokollerini kullanmak) en iyisi olabilir.

Biz MQTT iletim hızına kıyasla HTTP karşılaştırarak kesin test var, bakınız dnm2 mevcut senaryoda MQTT ardından HTTP sana 50 kat daha az trafik (ve pili) getirecektir.

Temel olarak MQTT ve düz TCP (mesaj boyutunda) arasında fark yoktur. Hatta temel TCP ve ikili mesaj ve MQTT yük JSON arasında hiçbir fark olmadığını söyleyebilirim. Bu şekilde, MQTT + JSON'u kullanmak ve veri dağıtımı ve sunumu için bu tekniklere güvenmek çok daha uygundur. Anahtarlarınızı az çok kısaca adlandırın.

UDP ile ilgili olarak, aktarım dakikada bir ise, TCP kullanmak daha iyidir. İletim 10-20 dakikada bir veya daha fazla ise, UDP'yi daha fazla trafik / pil etkin çözüm olarak düşünebilirsiniz. ACK'larla kendi protokolünü geliştirmeye çalışacaksanız, MQTT veya TCP kullanmanızı ve iş durumunuza odaklanmanızı öneririm.

Genel olarak - ne kadar basit uygularsanız, en kısa sürede elde edebileceğiniz en iyi sonuçları alın. Siz olsaydım, bu durumda UDP + kendi ikili biçimini ve MQTT + JSON'u test edip bunlardan birini seçmeliydim. Ya da MQTT + JSON'dan yeni başladım ve benim durumum için uygun olup olmadığını düşünün.