XMPP มีค่าใช้จ่ายจำนวนมากสำหรับอุปกรณ์ IoT ที่ส่งข้อความสั้น ๆ บ่อยครั้งหรือไม่?

ฉันได้อ่านเกี่ยวกับ XMPP ว่าเป็นโปรโตคอลการสื่อสารที่มีศักยภาพสำหรับอุปกรณ์ IoT แต่หลังจากอ่านแหล่งข้อมูลหนึ่งแล้วฉันไม่แน่ใจว่าเป็นโปรโตคอลที่เหมาะสมหรือไม่หากคุณกังวลเกี่ยวกับค่าใช้จ่ายสำหรับแต่ละข้อความ

แหล่งข้อมูลนี้ระบุว่า:

อย่างไรก็ตาม XMPP มีปัญหาหลายอย่างที่ทำให้ไม่พึงประสงค์สำหรับ IOT PROTOCOLS ที่ถูกฝังไว้ ในฐานะที่เป็นโปรโตคอลบนพื้นฐานของ XML XMPP นั้นมีความละเอียดมากยิ่งกว่า HTTP และมีค่าใช้จ่ายด้านข้อมูลจำนวนมาก คำขอแลกเปลี่ยน / ตอบกลับเพียงครั้งเดียวเพื่อส่งข้อมูลหนึ่งไบต์จากอุปกรณ์เชื่อมต่อ IOT ไปยังเซิร์ฟเวอร์มากกว่า 0.5 kB

มีข้อกำหนดแบบร่างที่จะบีบอัด XMPP โดยใช้การเข้ารหัส XML ที่เรียกว่า effective XML Interchange (EXI) แต่ถึงแม้จะมี EXI ข้อมูลเดียวกันหนึ่งไบต์ก็จะได้รับโอเวอร์เฮดของโปรโตคอลนับร้อยไบต์จาก XMPP เพียงอย่างเดียว EXI ยังเป็นรูปแบบการประมวลผลที่ยากกว่าตัวเลือกอื่น ๆ เนื่องจากปัญหาเหล่านี้โดยทั่วไปจึงแนะนำให้หลีกเลี่ยงการใช้ XMPP ในแอปพลิเคชัน IoT ในตัว

อย่างไรก็ตาม XMPP ส่งเสริมตัวเองให้เหมาะกับแอพพลิเคชั่น IoT (แม้ว่าจะไม่ได้บอกว่ามันเป็นค่าใช้จ่ายต่ำ) ดังนั้นมันจึงแปลกที่จะแนะนำ / ส่งเสริมโปรโตคอล verbose ขนาดใหญ่ที่ดูเหมือนว่าขนาดใหญ่สำหรับอุปกรณ์ IoT

ค่าโสหุ้ยของ XMPP นั้นใหญ่พอ ๆ กับที่แหล่งข้อมูลแนะนำสำหรับข้อมูลจำนวนเล็กน้อยหรือไม่? ตัวอย่างเช่นจะมีค่าใช้จ่ายเท่าไรเมื่อส่งข้อความ 8 ไบต์?

นอกจากนี้ค่าโสหุ้ยยังดีมากหากใช้การบีบอัดEXI (ดังที่กล่าวไว้ในแหล่งที่มา) สิ่งนี้จะมาพร้อมกับหลุมพรางหรือไม่?

ในขณะที่มันยุติธรรมที่จะบอกว่า XML เป็น verbose ที่ควรจะอารมณ์กับการรับรู้ว่า verbosity นี้ไม่ได้ทั้งหมด "ค่าใช้จ่าย" ในความสัมพันธ์กับเนื้อหาเนื่องจากมันสรุปความหมาย; มันเป็นค่าใช้จ่ายที่มีอาการของโปรโตคอลใด ๆ ที่เน้นแบบไดนามิกซึ่งตรงข้ามกับโครงสร้างแบบคงที่ ตัวอย่างเช่น HTML เป็นรูปแบบที่ผ่อนคลายจริงๆของ XML ที่สื่อถึงเนื้อหาที่มีโครงสร้างแบบไดนามิกโครงสร้างที่อาจพิจารณาได้ว่าเป็นแง่มุมของเนื้อหา คุณสามารถแยกความแตกต่างเนื้อหาของตารางจากตารางเอง แต่ความจริงที่ว่าเนื้อหานั้นเป็นข้อมูลแบบตารางที่มีความสัมพันธ์เฉพาะนั้นเป็นส่วนประกอบสำคัญกับเนื้อหา ถ้าฉันใช้แต่ละเซลล์และส่งมันทั้งหมดเป็นสตริงยาวหนึ่งโครงสร้างนั้นและความสัมพันธ์เหล่านั้นหายไปและดังนั้นฉันจึงสูญเสียข้อมูลและไม่ใช่เนื้อหานั้น

ลองพิจารณาข้อความ 8 ไบต์ที่อาจเป็นข้อมูล tabluar บางส่วน ถ้าฉันใช้โปรโตคอลแบบสแตติกฉันสามารถส่งผ่านได้โดยไม่มีค่าใช้จ่ายเพิ่มเติมเพียงแค่กำหนดโปรโตคอลแบบนี้:

• แต่ละข้อความมีขนาด 8 ไบต์ดังนั้นเราไม่จำเป็นต้องระบุความยาวหรือรวมลำดับการยกเลิกใด ๆ
• แปดไบต์ถูกใช้เพื่ออ้างถึงกริด 2 x 2 ซึ่งแต่ละเซลล์มีค่า 16 บิต

หากข้อความทั้งหมดของฉันเป็นเช่นนั้นการใช้ XML, HTML หรือ XMPP อาจถือว่าไร้สาระ - ฉันกำลังสูญเสียแบนด์วิดท์บนส่วนประกอบโครงสร้างที่เหมือนกันเสมอและกำหนดไว้ล่วงหน้าแล้วและเสียเวลาคำนวณที่สอดคล้องกันทั้งสองด้าน หน้า HTML ขั้นต่ำที่เหมาะสมที่มีเพียงตาราง 2 x 2 ที่มีอักขระสองตัวในแต่ละเซลล์น่าจะเป็นอย่างน้อย 100 ไบต์เพื่อรองรับการจัดรูปแบบและค่าใช้จ่ายในโพรโทคอล

อย่างไรก็ตามหากข้อความของฉันไม่ตรงทั้งหมดดังนั้นให้ระบุว่าข้อความประเภทใดอาจไม่ใช่ส่วนที่แท้จริงของ "payload" แต่เป็นองค์ประกอบที่จำเป็นเนื้อหาที่ชาญฉลาด ฉันสามารถทำได้ด้วยการเพิ่มเพียงสองไบต์และแนะนำพลวัตมากขึ้น:

• ขณะนี้ข้อความมีความยาวผันแปรได้ 0-255 ไบต์และไบต์แรกระบุความยาว
• มี 256 รหัสสำหรับประเภทข้อความที่กำหนดไว้ล่วงหน้าที่ต่างกันซึ่งหนึ่งในนั้นคือ "2 x 2 ตาราง" นั่นคือไบต์ที่สอง

ตอนนี้เนื้อหาตาราง 8 ไบต์ของฉันต้องการโอเวอร์เฮด 2 ไบต์ แต่มีความเป็นไปได้ที่หลากหลายมากขึ้นในแง่ของประเภทข้อความที่สามารถส่งด้วยโปรโตคอลที่กำหนดเองนี้

มันยังคงใกล้เคียงกับความเป็นไปได้ของหน้า HTML หรือข้อกำหนด XML เนมสเปซ (หรือตั้งค่าดังกล่าวซึ่งเป็นสิ่งที่ XMPP เป็นหลัก )

ดังนั้นตามนั้นหากส่วนใหญ่สิ่งที่คุณกำลังทำคือการส่งข้อความ 8 ไบต์ง่ายๆ XMPP อาจเกินความจริง อย่างไรก็ตามไม่จำเป็นว่ามาก การอ้างสิทธิ์ว่า "การแลกเปลี่ยนคำขอ / ตอบกลับเพียงครั้งเดียวเพื่อส่งข้อมูลหนึ่งไบต์จากอุปกรณ์ที่เชื่อมต่อกับ IOT ไปยังเซิร์ฟเวอร์นั้นมีค่ามากกว่า 0.5 kB" ดูเหมือนว่าฉันจะจ้องมองที่RFC ที่เกี่ยวข้องเพื่อเป็นการพูดเกินจริง ฉันทำอย่างรวดเร็วฉันไม่เคยใช้หรือใช้ XMPP) ฉันไม่สงสัยเลยว่าคุณสามารถสร้างตัวอย่างเช่นนี้ได้ แต่นั่นอาจไม่ใช่ตัวอย่างที่น้อยที่สุด

เนื่องจากโปรโตคอลนั้นใช้ TCP เป็นตัวการสร้าง "สตรีม XML ที่ผ่านการรับรองโดย 'jabber: client' namespace" จะต้องได้รับการพิจารณาเป็นส่วนหนึ่งของข้อความถ้าเราทำสิ่งหนึ่งสิ่ง - อุปกรณ์ติดต่อกับเซิร์ฟเวอร์เพื่อส่ง 8 ไบต์ไปยังส่ง ข้อมูลตัดการเชื่อมต่อ หากความสัมพันธ์มีความคงทนมากขึ้นซึ่งมักจะอยู่ในบริบทของ IoT ดังนั้นเราสามารถสันนิษฐานได้ว่าอุปกรณ์มีการเชื่อมต่อกับปลายทางแล้ว ในกรณีนี้หากปลายทางสุดท้ายของข้อความคือเซิร์ฟเวอร์ (ตรงข้ามกับไคลเอนต์อื่นเซิร์ฟเวอร์จะส่งข้อความไปยัง), ดังนั้นโปรโตคอลค่าใช้จ่ายอาจน้อยที่สุด

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

ค่า "โอเวอร์เฮด" 33 ไบต์ เป็นสิ่งที่ควรค่าแก่การชี้ให้เห็นว่า XML คือข้อความดังนั้นหากข้อความของคุณมักเป็นเลขฐานสองก็จะมีความเหมาะสมน้อยลงเพราะข้อมูลนั้นจำเป็นต้องเข้ารหัส (เช่นไปที่ฐาน64 ) ซึ่งจะเพิ่มค่าใช้จ่ายและการคำนวณ ความต้องการ

ดังนั้นในที่สุด:

XMPP มีค่าใช้จ่ายจำนวนมากสำหรับอุปกรณ์ IoT ที่ส่งข้อความสั้น ๆ บ่อยครั้งหรือไม่?

หากมีการเชื่อมต่ออย่างต่อเนื่องและข้อความส่วนใหญ่ไม่มีโครงสร้างฉันก็ไม่คิดเช่นนั้น อย่างไรก็ตามหากคุณไม่ต้องการสิ่งที่เสนอ (พลวัตเกี่ยวกับโครงสร้าง) แสดงว่ามีวิธีการที่เหมาะสมกว่า

หากเรามีบริบทที่เซิร์ฟเวอร์กลางเดียวกำลังประมวลผลและ / หรือใช้ข้อความระหว่างอุปกรณ์ต่าง ๆ แม้ว่าอุปกรณ์ใด ๆ ที่ทำนั้นอาจจะง่ายและตรงไปตรงมาโปรโตคอลที่สามารถ encapsulate ข้อความที่หลากหลายจะยังคงมีประโยชน์ หากอุปกรณ์ไคลเอนต์มีทรัพยากร จำกัด เราสามารถเข้ารหัสโปรโตคอลจำนวนมากและการห่อแต่ละข้อความจากปลายนั้นกลายเป็นงานที่ง่ายมาก ฉันเชื่อว่าอุปกรณ์ IoT จำนวนมากที่ปรับใช้เซิร์ฟเวอร์ HTTP ทำเช่นนั้น (ซึ่งเป็นสิ่งที่ตรงกันข้ามกับ "ไคลเอนต์ง่ายเซิร์ฟเวอร์ที่ซับซ้อน") เซิร์ฟเวอร์เหล่านั้นไม่สามารถจัดการกับคำขอ HTTP ใด ๆ (ยกเว้นผ่านการปฏิเสธการฟอร์แมตล่วงหน้า) และมีชุดของสิ่งต่าง ๆ ที่กำหนดไว้อย่างชัดเจนและมุ่งเน้นที่จะทำและการตอบสนองที่พวกเขาจะส่ง

ก่อนอื่นฉันควรจะบอกว่า XML นั้นถูกใช้เพื่อห่อหุ้มข้อความเรียลไทม์ด้วยความสำเร็จและโดยเฉพาะอย่างยิ่งในการสื่อสาร IM และสถานะใน XMPP ดูเหมือนว่าจะมีบาง บริษัท ที่ต้องการใช้ประโยชน์จากความรู้ XML ของพวกเขาเพื่อพยายามค้นหาแอปพลิเคชันอื่นสำหรับระบบการแสดงข้อมูลนี้

อย่างไรก็ตามไม่ใช่ทุกคนที่เชื่อว่า XML เป็นคำตอบสำหรับทุกสิ่งในระบบการส่งข้อความ ตัวอย่างเช่นมีการเปลี่ยนแปลงที่เห็นได้ชัดเจนในช่วงไม่กี่ปีที่ผ่านมากับระบบออนไลน์ที่ใช้ JSON เป็นวิธีการเรียงลำดับข้อมูลแทนที่จะเป็น XML และถ้าฉันใส่หมวกนักพัฒนาของฉันไว้ครู่หนึ่งฉันจะบอกว่าเครื่องมือในการเข้ารหัส / ถอดรหัสจากภาษา การเป็นตัวแทน (เช่นใน Python, PHP, Javascript) ดูเหมือนจะง่ายกว่าการใช้ JSON มากกว่าการเทียบเท่ากับ XML แม้ว่า XML จะมีเวลามากกว่าที่จะได้คำตอบที่ถูกต้อง

XML เป็นการนำเสนอที่ยากสำหรับคอมพิวเตอร์ที่จะจัดการเนื่องจากต้องการตัวแยกวิเคราะห์ข้อความที่ค่อนข้างซับซ้อนและจากนั้นการแสดงลำดับชั้นบางชนิดเพื่อให้สามารถแยกข้อมูลในโปรแกรมได้ เนื่องจากมีข้อความจำนวนมากที่เกี่ยวข้องคุณจำเป็นต้องมีหน่วยความจำค่อนข้างน้อยสำหรับการเข้ารหัส / ถอดรหัส

บ่อยครั้งที่ดูเหมือนว่าไม่ชัดเจนว่า XML กำลังเพิ่มมูลค่าให้กับการแสดงข้อมูล: หากข้อความหลักไม่ได้เป็นลำดับชั้นลึกจากนั้นเพิ่มแกลบข้อความจำนวนมากดูเหมือนไม่จำเป็น แต่ขัดแย้งถ้ามีลำดับชั้นจำนวนมากแล้วถอดรหัสข้อความจาก การแสดงข้อความของมันจะเป็นงานที่หนักและต้องการทรัพยากรจำนวนมาก ประโยชน์ของการแสดงข้อความไม่ชัดเจนสำหรับฉัน: เมื่อเราเขียนและดีบักระบบการสื่อสารเป็นครั้งแรกเป็นเรื่องปกติที่จะใช้เครื่องมือตรวจสอบ / ถอดรหัส (ตัวอย่างเช่น Wireshark) เพื่อช่วยให้เราทราบว่าเกิดอะไรขึ้น ในระยะยาวทุกอย่างทำงานได้ดีและไม่มีมนุษย์คนใดที่จะต้องมองลึกเข้าไปในรายละเอียดของข้อความที่ส่งไปมา (เฉพาะคอมพิวเตอร์) คอมพิวเตอร์ต้องการเป็นตัวแทนไบนารี การเป็นตัวแทนข้อความต้นฉบับไม่มีประโยชน์ใด ๆ ที่เกี่ยวข้องในขั้นตอนการปรับใช้ใด ๆ

XML เป็นเรื่องยากสำหรับมนุษย์ในการอ่าน (และสร้างด้วยตนเอง) ในขณะที่ทำงานหนักสำหรับคอมพิวเตอร์ในเวลาเดียวกัน ดังนั้นจึงเป็นระบบที่ไม่เหมาะสำหรับคอมพิวเตอร์และไม่เหมาะสำหรับมนุษย์

ที่สำคัญ IoT มีข้อ จำกัด พิเศษบางประการที่ทำให้มีประสิทธิภาพ โดยทั่วไปอุปกรณ์ IoT จะมีกำลังการประมวลผลและการจัดเก็บที่ จำกัด อุปกรณ์ IoT อาจมีการเชื่อมโยงการสื่อสารที่ง่ายที่สุดที่อาจเป็นไปได้แม้จะไม่ใช่สแต็ก TCP / IP จะมีการออกแบบไมโครคอนโทรลเลอร์ที่หลากหลายไม่แม้แต่ในระดับความซับซ้อนที่จะใช้ระบบปฏิบัติการมาตรฐาน (เช่น Linux, Android) สิ่งนี้ จำกัด จำนวนของเครื่องมือที่ไม่ได้วางจำหน่ายซึ่งจะวางอยู่รอบ ๆ ที่นำเสนออินเทอร์เฟซ XML ที่ใช้งานง่าย

โดยสรุปฉันสงสัยว่าด้วย IoT การแทนข้อมูลจะดีกว่าในแต่ละกรณีขึ้นอยู่กับข้อ จำกัด ของฮาร์ดแวร์รูปแบบการสื่อสาร (เช่นการออกอากาศดาต้าแกรมความน่าเชื่อถือ ฯลฯ ) ความถี่ของการสื่อสารเป็นต้น XML ไม่ควรถูกมองว่าเป็นไซน์ใฐานะที่ไม่ใช่สำหรับ IoT

1. หลายปีก่อนฉันวิเคราะห์ความแตกต่างในการใช้งาน

   XMLในเครือข่ายการชำระเงินสำหรับการทำธุรกรรมการชำระเงิน (card_number, วันที่, เวลา, terminal_id และรายการองค์ประกอบเพิ่มเติม) เปรียบเทียบกับแบบดั้งเดิม

   ISO8583บิตแมป

2. XML มีค่าใช้จ่ายมาก หากคุณพิจารณาถึงผลกระทบในเครือข่ายที่มี 10,000+ โหนดแต่ละคนจะส่งข้อความมากกว่า 10 ข้อความต่อชั่วโมงต่อวันไปยังโฮสต์กลางจากนั้น XML ก็จะหมดและคุณต้องการสิ่งที่มีประสิทธิภาพมากกว่า