Apakah XMPP memiliki overhead besar untuk perangkat IoT yang mengirim pesan pendek dan sering?


10

Saya telah membaca tentang XMPP sebagai protokol komunikasi potensial untuk perangkat IoT tetapi, setelah membaca satu sumber, saya tidak yakin apakah itu benar-benar protokol yang sesuai jika Anda khawatir tentang overhead untuk setiap pesan.

Sumber ini menyatakan:

Namun, XMPP memiliki sejumlah masalah yang membuatnya agak tidak diinginkan untuk PROTOKOL IOT YANG DIBUTUHKAN. Sebagai protokol berbasis XML, XMPP sangat verbose, bahkan lebih dari HTTP, dan memiliki overhead data yang berat. Pertukaran permintaan / respons tunggal untuk mengirim satu byte data dari IOT CONNECTED DEVICE ke server lebih dari 0,5 kB.

Ada spesifikasi rancangan yang akan mengkompres XMPP menggunakan pengkodean XML yang disebut efisien XML Interchange (EXI). Tetapi bahkan dengan EXI, satu byte data yang sama mendapat ratusan byte overhead protokol dari XMPP saja. EXI juga merupakan format yang jauh lebih sulit untuk diproses daripada opsi lain yang sekarang tersedia. Karena masalah yang melekat ini, umumnya disarankan untuk menghindari penggunaan XMPP dalam aplikasi IoT yang disematkan.

Namun, XMPP mempromosikan dirinya sebagai cocok untuk aplikasi IoT (meskipun tidak secara khusus mengatakan bahwa itu overhead rendah), sehingga tampaknya aneh bahwa protokol yang besar dan tampaknya bertele-tele akan direkomendasikan / dipromosikan untuk perangkat IoT.

Apakah overhead XMPP benar-benar sebesar yang disarankan sumber untuk sejumlah kecil data? Misalnya, berapa banyak overhead yang akan ada saat mengirim pesan 8-byte?

Juga, apakah overhead begitu hebat jika kompresi EXI digunakan (seperti yang disebutkan dalam sumber)? Apakah ini juga datang dengan beberapa jebakan?


4
Pertanyaan menarik. Meskipun saya tidak terbiasa dengan XMPP, penting untuk dicatat bahwa EXI membutuhkan kedua titik akhir untuk memiliki skema yang harus disinkronkan. Juga perangkat IoT harus en- decode xml yang tampaknya dengan sendirinya sangat kompleks untuk mengirim pesan 8-byte.
Helmar

1
@Helmar memang, dengan XMPP sepertinya apa yang Anda peroleh dalam ukuran paket, Anda kehilangan kompleksitas komputasi.
Aurora0001

1
Saya pikir pertanyaan ini umumnya baik-baik saja tetapi: "Misalnya, berapa banyak overhead yang akan terjadi ketika mengirim pesan 8-byte setiap 2 menit?" -> "Dua menit" adalah tangensial dan cenderung menyesatkan hal-hal. Apa yang Anda benar-benar tanyakan adalah berapa banyak overhead pesan 8 byte akan memiliki (saya kira, jika itu hanya satu bagian data, sama dengan pesan 1 byte). Sehubungan dengan komponen waktu ini hanya tergantung pada bandwidth dan bagi siapa pun yang merenungkan penggunaan protokol jaringan yang harus mati matematika sederhana.
goldilocks

1
@delicateLatticeworkFever Saya akan mengeditnya jika Anda tidak menganggapnya relevan (saya tidak sepenuhnya yakin tapi saya pikir lebih detail lebih baik daripada kurang)
Aurora0001

2
Itu saran, ya. Baru saja saya membaca, "Bukankah itu tergantung pada berapa lama waktu yang dibutuhkan perangkat yang tidak ditentukan untuk mengirim jumlah byte yang ditentukan?" Misalnya, jika jawabannya adalah bahwa pesannya ~ 0,5 kB, tidak ada elemen waktu dalam unit;) Itu ada dalam bandwidth perangkat yang tidak ditentukan.
goldilocks

Jawaban:


8

Meskipun adil untuk mengatakan bahwa XML itu verbose, itu harus diperlunak dengan kesadaran bahwa verbositas ini tidak semua "overhead" dalam kaitannya dengan konten karena itu merangkum semantik; itu overhead yang merupakan gejala dari setiap protokol yang menekankan dinamika sebagai lawan dari struktur statis. Sebagai contoh, HTML benar-benar bentuk santai dari XML yang menyampaikan konten dengan struktur dinamis, struktur yang dapat dianggap sebagai aspek konten. Anda bisa membedakan konten tabel dari tabel itu sendiri, tetapi kenyataan bahwa kontennya adalah data tabular dengan hubungan spesifik merupakan bagian integral dari konten; jika saya hanya mengambil setiap sel dan mentransmisikan semuanya sebagai satu string panjang, struktur itu dan hubungan itu hilang, jadi saya kehilangan informasi dan bukankah konten itu?

Mari kita pertimbangkan pesan 8 byte yang mungkin merupakan beberapa data tabluar. Jika saya menggunakan protokol yang sangat statis, saya bisa, secara minimal, mentransmisikannya tanpa overhead tambahan hanya dengan mendefinisikan protokol seperti ini:

  • Setiap pesan persis 8 byte, jadi kami tidak perlu menunjukkan panjangnya atau menyertakan urutan pengakhiran.
  • Delapan byte selalu diambil untuk merujuk ke kisi 2 x 2 di mana setiap sel berisi nilai 16-bit.

Jika semua pesan saya persis seperti itu, menggunakan XML, HTML atau XMPP mungkin dianggap konyol - saya menghabiskan bandwidth pada komponen struktural yang selalu sama dan telah ditentukan sebelumnya, dan membuang waktu perhitungan yang sesuai di kedua ujungnya membuat dan menguraikannya. Minimal, halaman HTML yang tepat yang hanya berisi tabel 2 x 2 dengan beberapa karakter di setiap sel mungkin akan setidaknya 100 byte untuk mengakomodasi pemformatan dan overhead protokol.

Namun, jika tidak semua pesan saya persis seperti itu, maka menentukan jenis pesan apa itu mungkin bukan bagian literal dari "payload" tetapi itu merupakan komponen yang diperlukan, konten-bijaksana. Saya bisa melakukannya hanya dengan dua byte tambahan dan memperkenalkan lebih banyak dinamika:

  • Pesan sekarang panjang variabel, 0-255 byte, dan byte pertama menunjukkan panjangnya.
  • Ada (hingga) 256 kode untuk berbagai jenis pesan yang telah ditentukan sebelumnya, salah satunya adalah "2 x 2 tabel", itu byte kedua.

Sekarang 8 byte konten tabel saya membutuhkan 2 byte overhead, tetapi ada berbagai kemungkinan yang lebih luas dalam hal jenis pesan apa yang dapat dikirim dengan protokol khusus ini.

Itu masih dekat dengan kemungkinan halaman HTML atau spesifikasi XML namespace (atau set darinya, itulah XMPP pada dasarnya ).

Jadi, berdasarkan itu, jika sebagian besar apa yang Anda lakukan adalah mengirim pesan 8 byte sederhana, XMPP mungkin berlebihan. Namun, belum tentu sebanyak itu. Klaim bahwa "pertukaran permintaan / respons tunggal untuk mengirim satu byte data dari IOT CONNECTED DEVICE ke server lebih dari 0,5 kB" tampaknya bagi saya, memandang sekilas pada RFC yang relevan , sebagai potensi yang dilebih-lebihkan (tetapi nb, semua Saya lakukan sekilas itu, saya tidak pernah menerapkan atau menggunakan XMPP). Saya tidak ragu Anda bisa membuat contoh seperti itu, tapi itu mungkin bukan contoh minimal .

Karena protokol berorientasi pada TCP, membuat "aliran XML yang memenuhi syarat oleh 'jabber: client' namespace" hanya perlu dianggap sebagai bagian dari pesan jika kita melakukan satu hal - perangkat menghubungi server untuk mengirim 8 byte, mengirim data, terputus. Jika hubungan lebih persisten, yang sering dalam konteks IoT, maka kita dapat menganggap perangkat sudah memiliki koneksi yang mapan ke tujuan. Dalam hal ini, jika tujuan akhir dari pesan adalah server (sebagai lawan dari klien lain server akan meneruskan pesan ke), maka overhead protokol berpotensi minimal.

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

A "overhead" sangat sedikit 33 byte. Perlu ditunjukkan di sini bahwa XML adalah teks, dan jadi jika pesan Anda sering bersifat biner, maka itu akan menjadi jauh lebih tidak tepat, karena data tersebut perlu dikodekan (misalnya, ke base64 ), yang menambah overhead dan komputasi lebih lanjut. Persyaratan.

Jadi, pada akhirnya:

Apakah XMPP memiliki overhead besar untuk perangkat IoT yang mengirim pesan pendek dan sering?

Jika ada koneksi yang terus-menerus dan pesan-pesannya sebagian besar tidak terstruktur, saya kira tidak. Namun, jika Anda tidak membutuhkan apa yang ditawarkannya (dinamisme terkait dengan struktur), maka mungkin ada metodologi yang lebih tepat.

Mengejar itu, jika kita memiliki konteks di mana server pusat tunggal sedang memproses dan / atau mengandalkan pesan antara berbagai perangkat, meskipun apa yang dilakukan oleh salah satu perangkat itu selalu sederhana dan mudah, sebuah protokol yang dapat merangkum sebuah variasi pesan akan tetap bermanfaat. Jika perangkat klien memiliki sumber daya yang terbatas, kami dapat melakukan hardcode pada sebagian besar protokol, dan membungkus setiap pesan dari sana menjadi tugas yang sangat sederhana; Saya percaya banyak perangkat IoT yang menggunakan server HTTP melakukan itu (yang merupakan kebalikan dari "klien sederhana, server kompleks"). Server-server itu tidak dapat menangani segala jenis permintaan HTTP (kecuali melalui penolakan yang telah diformat sebelumnya) dan memiliki serangkaian hal-hal yang akan dilakukan dengan baik dan tanggapan yang akan mereka kirim, tetapi karena tidak ada yang kurang berfungsi dengan benar sebagai server HTTP,


3

Pertama-tama, saya harus mengatakan bahwa XML telah digunakan untuk merangkum pesan waktu nyata dengan beberapa keberhasilan, dan pada skala besar, khususnya untuk berkomunikasi IM dan kehadiran di XMPP. Tampaknya juga ada beberapa perusahaan yang berniat memanfaatkan pengetahuan XML mereka untuk mencoba menemukan area aplikasi lain untuk sistem representasi data ini.

Namun, tidak semua orang yakin bahwa XML adalah jawaban untuk segalanya dalam sistem pengiriman pesan. Sebagai contoh, ada perubahan nyata dalam beberapa tahun terakhir ke sistem online yang menggunakan JSON sebagai cara untuk membuat serialisasi data daripada XML, dan jika saya memakai topi pengembang saya sebentar, saya akan mengatakan bahwa alat untuk menyandikan / mendekode dari asli representasi (misalnya dalam Python, PHP, Javascript) tampaknya jauh lebih mudah digunakan daripada untuk JSON daripada padanannya untuk XML, bahkan jika XML memiliki lebih banyak waktu untuk mendapatkan jawaban yang benar.

XML adalah representasi yang sulit untuk ditangani oleh komputer, karena membutuhkan parser teks yang relatif kompleks, dan kemudian semacam representasi hierarkis untuk memungkinkan datanya diekstraksi dalam suatu program. Karena ada begitu banyak teks yang terlibat, Anda memerlukan sedikit memori yang tersedia untuk pengodean / dekode.

Seringkali tampak tidak jelas bahwa XML menambahkan banyak nilai pada representasi data: jika pesan inti tidak terlalu hierarkis, maka menambahkan banyak sekam teks tampaknya tidak perlu, tetapi secara paradoksal jika ada banyak hierarki kemudian menguraikan pesan dari representasi tekstualnya akan menjadi kerja keras dan membutuhkan banyak sumber daya. Juga, manfaat dari mewakili dalam teks tidak jelas bagi saya: Ketika kami pertama kali menulis dan men-debug sistem komunikasi, adalah umum untuk menggunakan alat pemantauan / decoding (misalnya Wireshark) untuk membantu kami mencari tahu apa yang salah. Dalam jangka panjang, semuanya bekerja dengan baik, dan tidak ada manusia yang perlu melihat secara detail pada pesan bolak-balik (hanya komputer). Komputer lebih suka representasi biner. Representasi tekstual tidak menguntungkan siapa pun yang terlibat di setiap tahap penempatan.

XML sulit bagi manusia untuk membaca (dan secara manual membangun) sambil bekerja keras untuk komputer pada saat yang sama; Oleh karena itu sistem yang tidak cocok untuk komputer dan juga tidak cocok untuk manusia.

Yang penting, IoT memiliki beberapa kendala khusus yang membuatnya menjadi efisien. Perangkat IoT biasanya memiliki daya pemrosesan dan penyimpanan terbatas (biasanya tidak ada penyimpanan sekunder skala besar, hanya beberapa RAM dan EEPROM). Perangkat IoT mungkin memiliki tautan komunikasi yang paling sederhana, bahkan mungkin bukan tumpukan TCP / IP. Akan ada berbagai macam desain mikrokontroler, bahkan pada tingkat kecanggihan di mana sistem operasi standar (misalnya Linux, Android) akan digunakan; ini membatasi jumlah alat yang tersedia yang akan menawarkan antarmuka XML yang mudah digunakan.

Singkatnya, saya menduga bahwa dengan IoT, representasi data lebih baik dibiarkan berdasarkan kasus per kasus, tergantung pada kendala perangkat keras, gaya komunikasi (mis. Siaran, datagram, dll yang dapat diandalkan), frekuensi komunikasi dan sebagainya. XML tentu tidak seharusnya dianggap sebagai sine qua non untuk IoT.


3
  1. Beberapa tahun yang lalu saya menganalisis perbedaan untuk menggunakan

    XML dalam jaringan pembayaran untuk representasi transaksi pembayaran (card_number, tanggal, waktu, terminal_id, dan daftar elemen tambahan) dibandingkan dengan tradisional

    ISO8583 bit- maped

  2. XML memiliki overhead yang sangat besar. Jika Anda mempertimbangkan dampak dalam jaringan dengan 10.000 node masing-masing mengirim 10+ pesan setiap jam / hari ke host pusat maka XML keluar dan Anda benar-benar membutuhkan sesuatu yang lebih efisien.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.