MQTT version 5.0 เวอร์ชั่นใหม่คืออะไรไฉไลกว่าเดิมไหม ?
ในงานด้าน Internet Of Things โปรโตคอลในการสื่อสารที่ถูกนิยมนำมาใช้มากเป็นอันดับต้นๆ คือโปรโตคอล MQTT โดยเวอร์ชั่นที่ส่วนใหญ่ใช้กันในปัจจุบันคือ
3.1.1 แต่ตอนนี้หลายๆ ท่านน่าจะเริ่มเห็นเวอร์ชั่นใหม่ คือ MQTT Version 5.0 และปัญหาคือ 5.0 ไม่ backward compatible กับ 3.1.1 นะครับ เลยต้องมารู้จักกันซักหน่อยครับ เพื่อเตรียมวางแผนอัพเกรดระบบกัน
ความเป็นมาของเวอร์ชั่น 5.0 ในวันที่ 9 เดือนสิงหาคม 2017 OASIS MQTT Technical Committee ผู้ดูแลมาตรฐานของโปรโตคอล MQTT ได้ประกาศ Public Review เวอร์ชั่น 5.0 ขึ้นมา และหมดเขตในวันที่ 8 กันยายน 2017 หลังจากนั้นก็มีการปรับปรุงกันมาและ Official Release ในเดือน ธันวาคม 2017 ในช่วงแรกซอฟต์แวร์ยังไม่ค่อยรองรับเท่าไหร่ แต่ในปัจจุบันทั้ง IoT sensor, Hardware, Broker ต่างรองรับกันแล้วครับ
MQTT Version 4.0 หายไปไหน
แต่ก่อนอื่นสงสัยไหมครับทำไมเป็น MQTT 5.0 ทั้งที่เวอร์ชั่นก่อนหน้าเป็น
MQTT 3.1.1
เพื่อไขปริศนานี้เราต้องมาดู CONNECT Message ของ MQTT ที่ Client หรืออุปกรณ์ IoT จะใช้ต่อไปที่เซอเวอร์กัน
MQTT จะใช้ตัวแปร 8 bit สำหรับแสดงเวอร์ชั่นของโปรโตคอลโดยค่าที่ใช้แสดงเวอร์ชั่น 3.1.1 คือ 4 (0x04) ดังนั้นเวอร์ชั่นต่อมาจึงกระโดดเป็น 5 เลย
อะไรใหม่ใน MQTT 5.0
MQTT 5.0 Goals
OASIS MQTT Technical Committee ตัดสินใจออกแบบ MQTT 5.0 โดยมีเป้าหมายดังต่อไปนี้
- Enhancement for scalability and large scale systems
- Improved error reporting
- Formalize common patterns including capability discovery and request response
- Extensibility mechanisms including user properties
- Performance improvements and support for small clients
Foundational Changes สิ่งหลักๆ ที่เปลี่ยนไป
MQTT Version 5.0 ก็ยังเป็น MQTT เหมือนเดิมที่เคยรู้จัก
ข่าวดีคือ ถ้าท่านใดเคยใช้ MQTT มาก่อนแล้ว ในเวอร์ชั่นใหม่นี้หัวใจสำคัญของระบบก็ยังเหมือนเดิม ยังสามารถออกแบบระบบเหมือนเดิมได้เลย
บางฟีเจอร์เช่น Last Will and Testament จะถูกเปลี่ยนนิดหน่อย หรือบางฟีเจอร์ถูกเพิ่มเข้ามาเช่น TTL หรือ Shared Subscriptions
Properties in MQTT Header & Reason Codes
หนึ่งในฟีเจอร์ที่ทำให้ระบบหยืดหยุ่นมากขึ้นและน่าสนใจที่สุดของเวอร์ชั่นนี้คือ MQTT 5 สามารถที่จะ custom key-value propoties หรือ user propertiesใน MQTT Header ได้แล้ว บางสำนักถึงกับบอกว่าเป็น Game changer เพื่อตัดสินใจไปใช้งานจริงของ MQTT Version นี้เลยทีเดียว
ส่วน Reason Codes เป็นรูปแบบของข้อมูลที่ถูก pre-defined ของ MQTT ไว้อยู่แล้ว เพื่อบอกปัญหาของระบบที่เกิดขึ้น.
Reason Code ปกติจะถูกส่งไปพร้อมกับ Ack Packets ทำให้ Client หรือ Broker สามารถที่จะแปลความหมายของ error ที่เกิดขึ้นได้ Reason Codes หรือจะเรียกว่า
Negative Acknowledgement โดย MQTT Packet ดังต่อไปนี้สามารถขน Reason Codes ไปได้แก่
- CONNACK
- PUBACK
- PUBREC
- PUBREL
- PUBCOMP
- SUBACK
- UNSUBACK
- AUTH
- DISCONNECT
User Properties คืออะไรและทำงานอย่างไร
ใน MQTT5 User Properties มีลักษณะเป็น UTF-8 string ที่เราสามารถใส่ลงไปในทุกๆ MQTT Packet ได้. รวมไปถึงคอนโทรล Packet เช่น PUBREL, PUBCOMP ตราบใดที่ไม่เกินขนาดสูงสุดของข้อมูลที่ส่งได้ เราสามารถใส่ User Properties ได้ไม่จำกัด เพื่อส่งข้อมูล ( Information ) นี้ผ่านระหว่าง Publisher, Broker, Subscriber ฟีเจอร์นี้เหมือน HTTP Header นั่นเอง
ทำไม User Properties ถึงถูกแนะนำและควรนำมาใช้
MQTT Version 3 มักถูก user พูดถึงเรื่องของ lack extensibility ตัวโปรโตคอล
ความยากในการสร้างระบบที่มีลูกค้าหลายเจ้าและต้องการแยกจากกัน
ดังนั้นเมื่อ User Properties มาถึง เราจึงสามารถใส่ข้อมูลเช่น ข้อมูลกลุ่มลูกค้า เป็น metadata หรือสามารถปรับแต่งให้ตรงกับความต้องการของแต่ละทีมได้
มาดูตัวอย่าง Use Case ที่ใช้ User Properties กัน
- ประหยัดทรัพยากรของระบบด้วยข้อมูล metadata แทนการใส่ใน payload
ในสถานการณ์ที่มีการออกแบบระบบ MQTT สำหรับเชื่อมต่อหลายๆ ระบบ และถูกพัฒนาโดยหลายทีม , ข้อมูล payload structure เป็นไปยากที่จะทำให้ใช้ร่วมกันได้เป็นอย่างดี ไคลเอนต์บางตัวอาจส่งข้อมูลเป็น JSON บางตัวเป็น XML บางตัวเป็น ProtoBuf
ดังนั้นเช่นในสถานการณ์นี้ การใส่ User Properties จะช่วยบอกชนิดของ Protocol, Version หรือวิธีการ Encode format ได้ ดังนั้น Client จึงไม่ต้องมานั่งพยามเช็คว่าข้อมูลที่ส่งมาเป็นอะไร และทดลองถอดข้อมูลด้วยหลายๆ รูปแบบเป็นต้น
- ติดตามการส่งข้อมูลตรวจสอบย้อนกลับ ในระบบที่มีความซับซ้อนได้ง่ายขึ้น
การวางระบบ IoT มักจะมีความซับซ้อน
ใน MQTT Version 3.1.1 subscriber การรู้ว่าใครเป็นคน publish ข้อมูลที่ได้รับมาไม่สามารถดูได้ในระดับของ MQTT Protocol ถ้าจะรู้อาจจะเป็นวิธีการ subscriber เลือก subscribe topic ที่เป็น unique id ของอุปกรณ์ที่ส่ง หรือผู้ส่งจำเป็นต้องฝัง Client ID ของตัวเองมากับ publish message เท่านั้น
แต่ในเวอร์ชั่น 5.0 นี้เราสามารถใส่ข้อมูลของ Client ID เข้าไปได้เลย ข้อมูลนี้จะถูก forward ต่อไปโดยไม่ต้องมานั่งคิด logic ในการถอดเพิ่มเติมกันอีก หรือจะแปลงเป็นโปรโตคอลอื่นเช่น HTTP ก็สะดวกขึ้น
สรุปของ User Properties
- User Properties เป็น UTF-8 String ที่สามารถใส่ลงไปได้ในทุกๆ MQTT Packet
- เพิ่มโอกาสในการขยายลอจิกเพิ่มเติมของโปรโตคอล MQTT ที่ปกติถูกจำกัด
- ระบบที่ต้องใช้ในหลายๆ system หลายผู้พัฒนา หรือต้องแปลงโปรโตคอล สามารถคุยกันได้ง่ายขึ้น โดยใช้วิธีการดู User Properties ก่อนจะเข้าไปถอด payload
ก็จบไปแล้วนะครับสำหรับ introduction และเรื่อง user properties
ส่วนการตัดสินใจว่าจะอัพเกรดระบบหรือใหม่ขึ้นอยู่กับผู้ออกแบบแล้วครับ แต่เท่าที่รีวิวฟีเจอร์นับว่าน่าสนใจมาก ไม่ได้เพิ่มให้ยุ่งยากมากขึ้นแต่เป็นสิ่งที่ควรจะมีตั้งนานแล้ว MQTT V5.0 ส่วนที่น่าสนใจยังไม่หมด
หัวข้อที่น่าสนใจและถ้าเขียนต่อได้อีกคือ
- Reason Codes
- Cleans session เปลี่ยนเป็น Clean Start
- AUTH Packet อันนี้ดีมากโดยเฉพาะการออกแบบเรื่อง Authentication
- Session & Expinary Interval
- Share Subscription and TTL
