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,