MQTT ครบ 25 ปี

 (andypiper.co.uk)
4 คะแนน โดย GN⁺ 2024-10-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MQTT เป็นโปรโตคอลที่เริ่มจากการเผยแพร่สเปกครั้งแรกในเดือนตุลาคม 1999 และตลอด 25 ปีที่ผ่านมาได้ขยายจากโปรโตคอลน้ำหนักเบาสำหรับอุปกรณ์ขนาดเล็กและเครือข่ายที่ไม่เสถียร ไปสู่การใช้งานในภาคอุตสาหกรรม บ้าน และแอปต่าง ๆ
  • โครงสร้าง publish/subscribe ที่เรียบง่าย ซึ่งออกแบบมาบนสมมติฐานของพลังงานจำกัดและการเชื่อมต่อที่ขาดช่วง ยังคงเป็นจุดแข็งแม้สภาพแวดล้อมของเครือข่ายและอุปกรณ์เอดจ์จะเปลี่ยนไปแล้ว
  • MQTT ที่เคยถูกใช้งานอยู่รอบ ๆ IBM เริ่มแพร่หลายสู่ชุมชนอย่างจริงจังในช่วงปี 2009~2011 และขยายออกเป็นระบบนิเวศของโปรโตคอลเปิดนอก IBM ผ่าน Mosquitto และ Eclipse Paho
  • ปัจจุบัน MQTT ถูกใช้อยู่ในหลายที่โดยที่ผู้ใช้ไม่ทันสังเกต เช่น การประมวลผลข้อความบน Raspberry Pi ที่ใช้ Node-RED, เครื่องฟอกอากาศ Dyson และแอป, การควบคุมเครื่องพิมพ์ 3D, การแจ้งเตือนภายในบ้าน และโรงงานการผลิต
  • ในวาระครบรอบ 25 ปี ชุมชนได้ย้ายจากบัญชีโปรเจกต์เก่าบน X ไปยัง Mastodon ที่ @mqtt@fosstodon.org และโพสต์ข้อความแรกบน Fediverse ที่ใช้ ActivityPub แล้ว

การรับส่งข้อความแบบน้ำหนักเบาที่เริ่มจากสภาพแวดล้อมจำกัด

  • เดือนตุลาคม 2024 เป็นช่วงครบรอบ 25 ปี นับจากการเผยแพร่เอกสารที่ต่อมาได้นำไปสู่สเปกแรกของ MQTT
  • MQTT เป็นโปรโตคอลเครือข่ายที่ออกแบบโดยตั้งสมมติฐานถึงอุปกรณ์ขนาดเล็กและมีข้อจำกัดในช่วงปลายทศวรรษ 1990 รวมถึงเครือข่ายที่เบาหรือไม่เสถียร
  • จุดเน้นคือการส่งข้อมูลจากเซนเซอร์ไปยังระบบที่ใหญ่กว่า ในสถานการณ์ที่การเชื่อมต่อขาดช่วงและพลังงานมีจำกัด เช่น อุปกรณ์ตรวจวัดสภาพแวดล้อมที่อยู่ห่างไกล
    • อุปกรณ์เหล่านี้ต้องใช้พลังงาน แบนด์วิดท์ และความพร้อมใช้งานของเครือข่ายอย่างประหยัด
    • MQTT เหมาะกับวิธีการเผยแพร่และเก็บรวบรวม/รับข้อมูลในรูปแบบที่เล็กแต่ใช้งานได้จริง
  • แม้เครือข่ายจะเร็วขึ้นและเสถียรมากขึ้น และมีอุปกรณ์เอดจ์ ระบบบ้านอัตโนมัติ และอุปกรณ์พกพาเพิ่มขึ้น ความเรียบง่ายของโปรโตคอล ก็ยังคงเป็นจุดแข็งหลักของ MQTT

จากรอบ ๆ IBM สู่ระบบนิเวศแบบเปิด

  • หลังเข้าร่วม IBM ในปี 2001 ผู้เขียนได้ทำโปรเจกต์ลูกค้าที่เกี่ยวข้องกับ IBM MQ, การบูรณาการทางธุรกิจ, message queuing, การเชื่อมต่อแอปพลิเคชัน และมิดเดิลแวร์
  • IBM Hursley Lab เป็นฐานสำคัญของ MQ และยังเป็นสถานที่ทำงานของ Andy Stanford-Clark ผู้ร่วมสร้าง MQTT ทำให้การทดลองเกี่ยวกับ MQTT เริ่มต้นขึ้นรอบ ๆ ที่นั่น
  • ในเวลานั้น MQTT แม้จะถูกเปิดเผยออกสู่ภายนอกในฐานะโปรโตคอลแล้ว แต่ยังไม่ค่อยเป็นที่รู้จักหรือถูกนำไปใช้อย่างแพร่หลายนอก IBM
  • ราวปี 2009~2011 เริ่มมีความคืบหน้าในการทำให้ MQTT เป็นที่รู้จักนอกขอบเขตการใช้งานขนาดเล็กภายใน IBM
    • ในเวลานั้นตัวเลือกของ broker ได้แก่ IBM WebSphere Message Broker สำหรับองค์กรที่มีราคาแพง, microbroker แบบปิดซอร์ส และ Really Small Message Broker ที่ปิดซอร์สแต่เปิดให้ใช้ฟรี
    • Mosquitto แบบโอเพนซอร์สที่สร้างโดย Roger Light เป็นหนึ่งใน implementation ฟรีที่ยังถูกใช้อย่างแพร่หลายจนถึงปัจจุบัน
    • Roger Light สร้าง Mosquitto หลังจากฟังการนำเสนอเรื่องสมาร์ตโฮมที่เชื่อมต่อกันของ Andy Stanford-Clark ในงาน OggCamp ครั้งแรกเมื่อปี 2009 ซึ่งเกิดขึ้น 10 ปีหลังจากวันที่สร้างสเปก

Eclipse Paho และการทำให้เป็นมาตรฐานอย่างเป็นทางการ

  • ในปี 2011 implementation ของ MQTT จาก IBM ถูกบริจาคให้กับชุมชน Eclipse จนเกิดเป็นโปรเจกต์ Eclipse Paho
  • แม้ออกจาก IBM ในปี 2012 ความเชื่อมโยงกับโปรเจกต์ Paho ก็ยังดำเนินต่อไป และยังรับบทบาทนี้ในช่วงที่ทำงานกับ Cloud Foundry
  • หลังเข้าร่วม Twitter ในปี 2014 ผู้เขียนก็ถอยออกจากการมีส่วนร่วมอย่างเป็นทางการ
  • ในช่วงนั้น MQTT ได้ผ่านกระบวนการมาตรฐานอย่างเป็นทางการกับ OASIS และ ISO/IEC

MQTT ในที่ที่มองไม่เห็นทุกวันนี้

  • MQTT ได้ก้าวข้ามขอบเขตของ IBM และกลายเป็น กรณีศึกษาความสำเร็จของโปรโตคอลเปิด โดยหลังผ่านไป 25 ปี มันได้เข้าไปอยู่ในผลิตภัณฑ์และสถานที่มากมายที่ผู้ใช้ไม่ทันรับรู้
  • ตัวอย่างการใช้งานที่เด่น ๆ ได้แก่
    • โปรเจกต์ของนักพัฒนาสายงานอดิเรกและเมกเกอร์
    • เครื่องฟอกอากาศ Dyson และแอปที่เกี่ยวข้อง
    • ระบบควบคุมเครื่องพิมพ์ 3D
    • ระบบแจ้งเตือนภายในบ้าน
    • ภาคอุตสาหกรรมและโรงงานการผลิต
  • แม้แต่ในพื้นที่ทำงานส่วนตัว MQTT ก็ถูกใช้งานอยู่หลายรูปแบบ
    • เครื่องพิมพ์ 3D Bambu Lab X1C ใช้ MQTT สำหรับการสื่อสารภายใน
    • อุปกรณ์เชื่อมต่อที่ติดอยู่บนผนังตอบสนองต่อการแจ้งเตือนผ่าน MQTT เพื่อแสดงข้อมูลหรือเปิดไฟ
    • Node-RED ที่รันบน Raspberry Pi ทำหน้าที่ประมวลผลข้อความ MQTT
  • มีความเป็นไปได้สูงว่าอย่างน้อยหนึ่งแอปในโทรศัพท์ของคุณกำลังใช้ MQTT อยู่ที่ใดที่หนึ่งในสแตก

ครบรอบ 25 ปีและการย้ายของชุมชน

  • บัญชีชุมชนของ MQTT ได้ย้ายไปยัง Mastodon แทนบัญชีโปรเจกต์เดิมบน X
  • สามารถติดตามบัญชีใหม่ได้ที่ @mqtt@fosstodon.org
  • เพื่อฉลองครบรอบ 25 ปี MQTT ได้โพสต์ข้อความแรกบน Fediverse ผ่าน ActivityPub และเข้าร่วม open social web
  • Andy Stanford-Clark ได้พูดคุยแบบ fireside chat กับ HiveMQ และยังแนะนำพอดแคสต์ของ HiveMQ ชื่อ The Unstructured Message ว่าเป็นอีกแหล่งสำหรับติดตามเนื้อหาเกี่ยวกับ MQTT

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-23
ความคิดเห็นบน Hacker News

  • โปรเจกต์แรกที่ยัง ใช้งานอยู่ และถูกใช้ทุกวัน คือการนำแผนที่ SVG ของระบบน้ำ—ท่อ/ปั๊ม/วาล์วสำหรับทำหิมะและดับเพลิง—ของสกีรีสอร์ตขนาดใหญ่ มาทำเป็นเว็บไซต์แสดงสถานะ
    สร้าง MQTT topic สำหรับปั๊ม วาล์ว และช่วงท่อแต่ละส่วน แล้วผูกสถานะอย่างทิศทางการไหลของน้ำ การเปิด/ปิดปั๊ม/วาล์ว และแรงดัน จากนั้นใช้ mqtt.js กับ jQuery เพื่ออัปเดตสีและการเติมสีของ SVG
    MQTT broker ที่รันเป็นคอนเทนเนอร์บน static hosting ทำงานมาเกือบ 10 ปีโดยแทบไม่ต้องแตะต้อง และ mqtt.js ทำงานบน WebSocket ทำให้เมื่อสถานะเปลี่ยนก็สะท้อนให้ทุกคนเห็นโดยอัตโนมัติ

    • น่าทึ่งที่ Docker เป็นเทคโนโลยีที่มีอายุ 11 ปี แล้ว

  • ลองใช้ MQTT ในโปรเจกต์ล่าสุด แต่ไม่ได้ประทับใจมากนัก
    โปรโตคอลมีตัวเลือกเยอะ และยากที่จะเข้าใจได้ทันทีว่าแต่ละตัวเลือกทำอะไร ทำไมจึงสำคัญ และควรใช้ร่วมกันแบบไหนจึงจะทำงานตามที่ตั้งใจ เอกสารก็อธิบายส่วนนี้ได้ไม่ดีนัก
    บางส่วนอาจเป็นเพราะ Eclipse Mosquitto Python client ที่ใช้ก็ได้ แต่บนระบบที่ช้าเกิด race condition จนการ subscribe topic ถูกเพิกเฉยไปเงียบ ๆ และ callback พัง ต้องใช้เวลาหลายวันกว่าจะหาเจอ
    ทั้งที่ทำตามเอกสาร 100% ก็ยังเป็นแบบนั้น และสำหรับโปรโตคอลที่ไม่ได้เก่ามาก นี่เป็นหนึ่งในประสบการณ์ที่เละเทะที่สุด

    • ในกรณีนี้ดูเหมือน client จะไม่ค่อยดีเท่านั้นเอง
      ประสบการณ์กับ Eclipse clients เช่น Paho ที่เคยใช้ใน Python และ C++ ก็คล้ายกัน คือซับซ้อนเกินไป รู้สึก low-level เกินไป และมีบั๊กอยู่บ้างจากโครงสร้างของมัน
      น่าจะเป็นเพราะอยู่ในระดับที่แทบมีคนดูแลหลักเพียงคนเดียว เมื่อเวลาผ่านไปจึงกลายเป็นแบบนี้ C++ client ก็มีผู้ร่วมพัฒนาเพียงคนเดียวในช่วง 6 เดือนล่าสุด และ 3 เดือนล่าสุดไม่มีใคร contribute เลย
      PR ง่าย ๆ ที่แก้บั๊กชัดเจน ระดับเปลี่ยนแค่คำเดียว ยังใช้เวลา 2 ปีกว่าจะรีวิวและ merge ได้ ไม่ได้หมายจะตำหนิ แต่หมายความว่าดูเหมือนมีไลบรารี บั๊ก และงานจำนวนมากที่คนกลุ่มเล็ก ๆ ซึ่งทำงานหนักเกินไปต้องรับมือ
      พอย้ายไปใช้ client อื่น ประสบการณ์ใน Python, Rust, C#, C++ ดีขึ้นมาก และส่วนใหญ่มีการผสม API ระดับสูง/ต่ำที่ดี ถ้าแค่อยากส่งข้อความไปยัง topic ก็ไม่ต้องสนใจเรื่อง acknowledgement หรือ retry
      แต่ถ้าต้องการควบคุมก็ยังควบคุมได้ กังวลว่าการปล่อยให้ paho และตัวอื่น ๆ มีชีวิตอยู่ในสภาพนี้อาจเป็นโทษมากกว่าเป็นประโยชน์หรือไม่ ถ้าประกาศอย่างเป็นทางการว่าตายแล้ว อย่างน้อยปัญหาก็จะถูกบังคับให้เผยออกมา แต่ตอนนี้ผู้ใช้เจอประสบการณ์แบบนี้แล้วเลิกใช้ MQTT หรือคิดว่าตัวเองทำอะไรผิด
    • ใช้ MQTT ผ่าน paho Python MQTT library มาตลอด และสร้างอะไรได้ค่อนข้างเยอะ แต่โดยรวมเป็นประสบการณ์ที่แย่มาก
      ทั้งการออกแบบ API เอกสารที่ขาดแคลน และแนวทางที่ดูเหมือนไม่ตามธรรมเนียมของ Python ล้วนทำให้หงุดหงิด
      ตอนเริ่มต้นดูเหมือนง่าย แต่ความกว้างของโปรโตคอลและ implementation ค่อย ๆ กลายเป็นตัวถ่วง ครั้งหนึ่ง วิธีที่เชื่อถือได้ในการตรวจสอบว่าเชื่อมต่อกับเซิร์ฟเวอร์สำเร็จหรือไม่ คือการ subscribe topic เดิมสองครั้ง แล้วจับ error code เฉพาะในข้อความ on_connect ซึ่งตอนนั้น code นั้นถูกระบุในเอกสารว่าเป็น success code
      รู้ว่าฟังดูไร้เหตุผล แต่ถึงจะมีวิธีที่ดีกว่า ก็คงหาได้ไม่ง่าย อย่างไรก็ตาม การบ่นเป็นเรื่องง่าย และขอขอบคุณผู้คนมากมายที่สร้างไลบรารีนี้ขึ้นมา ถ้าไม่มีพวกเขา สิ่งที่สร้างอยู่ตอนนี้ก็คงสร้างไม่ได้ และนับถือคนที่รับผิดชอบโปรเจกต์ขนาดใหญ่แบบนี้
    • เคยใช้ Paho API ใน Python, C, C++ แต่สุดท้ายเลิกใช้ทั้งหมด
      ถ้าเป็นไปได้ เลือกให้ mosquitto_sub กับ mosquitto_pub จัดการโปรโตคอล แล้วอ่านเขียนเฉพาะ standard input/output แทน
      ไม่ใช่แค่เพราะบั๊ก แต่เพราะการฝากการจัดการการเชื่อมต่อกับ broker ให้โปรแกรมที่เขียนและทดสอบมาแล้วทำให้ง่ายกว่า
      อย่างไรก็ตาม วิธีนี้ใช้กับ will message ได้ไม่ค่อยมีประสิทธิภาพ และไม่เหมาะกับไมโครคอนโทรลเลอร์ที่ไม่ได้รันอะไรอย่าง Linux
    • แม้จะไม่ได้แข่งกับ MQTT โดยตรง แต่ https://pipe.pico.sh เป็น เครื่องมือ publish/subscribe ที่ยอดเยี่ยมสำหรับสื่อสารผ่าน SSH
      โดยพื้นฐานแล้วมันสร้างระบบ pipe แบบ *nix ผ่านเครือข่ายที่ผ่านการยืนยันตัวตน และมุ่งเป็นวิธีที่ง่ายที่สุดในการส่งและรับ event
    • เคยเห็นที่ไหนสักแห่งว่า “ใช้ TCP เฉย ๆ ไม่ได้เหรอ” และสำหรับ โปรเจกต์ IoT ของผม TCP ธรรมดาก็เพียงพอแล้ว
      สำหรับ use case ของผม คิวแบบไม่จำกัดเป็นเรื่องสำคัญ แต่ MQTT ไม่ได้ให้สิ่งนั้น และถ้าผมต้องจัดการ message ID เอง เพื่อให้ MQTT ติดตาม message ID ของมันเองแล้วส่งไปยัง broker ก็ไม่มีเหตุผลมากนักที่จะใช้
      ถ้าไม่ได้เชื่อมต่อกับโปรเจกต์ที่ปรับมาให้เข้ากับ MQTT อยู่แล้ว ก็ไม่ค่อยแน่ใจว่า use case ที่เหมาะที่สุดคืออะไร

  • ในช่วงไม่กี่ปีมานี้ MQTT ถูกใช้มากขึ้นมากในการแชร์ข้อมูลระหว่างเครื่องจักรภายในโรงงาน
    ในอดีตเคยใช้ในภาค Oil & Gas สำหรับงาน SCADA เพื่อดึงข้อมูลจากไซต์บ่อน้ำมันระยะไกล
    กว่า 10 ปีก่อนเคยเพิ่ม MQTT เข้าไปใน Kepware (OPC server) เพื่อสตรีมค่าแท็กขึ้น “คลาวด์” หลังจากพรีเซนต์เสร็จ Arlen Nipper หนึ่งในผู้สร้าง MQTT ก็มาหาแล้วบอกว่า “ทำได้ไม่เลว” ทำให้รู้สึกถ่อมตัวขึ้นเลย
    ตอนนี้อยู่บริษัทใหม่ชื่อ HighByte ทำการโมเดลข้อมูลโรงงานที่ edge แล้วส่งออกไปทาง MQTT, SparkplugB (โปรโตคอลบน MQTT), S3, Azure Blob ฯลฯ
    สรุปคือ MQTT เป็นแรงขับเคลื่อนสำคัญของ Industry 4.0 และมันเจ๋งที่เวลาผ่านมานานแล้วก็ยังถูกใช้อย่างแพร่หลายขนาดนี้

    • ตอนนี้ใช้ Kepware IoT plugin สตรีมแท็กประมาณ 800,000 แท็กต่อวินาที ผ่าน MQTT แล้วสุดท้ายส่งเข้า VictoriaMetrics DB
      ค่อนข้างดิบ ๆ และมีขั้นตอนประมวลผลมากกว่าที่อยากได้ Kepware คิดค่าไลเซนส์แบบ recurring รายปีสำหรับ IoT plugin เลยตอนนี้กำลังย้ายออกจากโซลูชันนั้น ไปทางให้ telegraf อ่านข้อมูล OPC-UA จาก Kepware โดยตรงแทน
      สงสัยว่าเคยทำงานหรือกำลังทำงานที่ Kepware อยู่หรือเปล่า
    • ทำงานในอุตสาหกรรมเดียวกัน และค่อนข้างงงกับความด้อยทางเทคนิคของ มาตรฐาน OPC Foundation การขยาย scope และอาการ NIH syndrome
      อยากให้ใช้ Sparkplug B ไปเลย แล้วค่อย implement สเปกสำหรับ semantics ทับบนมัน
      แถมงานเกี่ยวกับ asynchronous ที่ทำกันอยู่ตอนนี้ก็ over-engineer มากและแย่มาก เคยเข้าร่วมประชุมอยู่พักหนึ่ง แต่ทั้งที่สเปก MQTT มีไม่ถึง 50 หน้าและอ่านง่าย พวกเขากลับไม่เคยอ่าน และไม่เข้าใจด้วยว่า header มีไว้เพื่ออะไร เช่น พยายามจะใส่สิ่งที่จริง ๆ ควรอยู่ใน payload ลงไปใน header
      คนหนึ่งจากฝั่ง Microsoft ถึงกับไม่พอใจข้อเสนอที่ว่าให้ดูก่อนว่าคู่แข่งทำอะไรกับ MQTT อยู่บ้าง เพราะเขาอยากสร้างใหม่มากกว่าลอกเลียน
      จากข้อเสนอของผม บริษัทเราจะจัดการ OPC UA เฉพาะที่ edge ชั้นนอกสุดเท่านั้น และจะแยกมันออกจากเทคโนโลยีของเราให้มากที่สุด
    • ผมเองก็เจอ MQTT ครั้งแรกในด้าน การผลิตเคมีภัณฑ์ และก็เห็นใช้เยอะในระบบควบคุมการบินกับรถไฟด้วย
      แต่ช่วงนี้ก็เห็น Kafka กับ RabbitMQ รุกเข้ามาในพื้นที่ตลาดของ MQTT มากขึ้นเหมือนกัน
    • สงสัยว่า MQTT กำลังถูกใช้ในที่ที่เมื่อก่อนคงใช้ Modbus หรือเปล่า

  • ราว 15 ปีก่อน ตอนที่อุปกรณ์ IoT ที่ทวีตได้ยังไม่ใช่เรื่องธรรมดา บ้านของ Andy Stanford Clark เคยเป็นข่าวอยู่พักหนึ่ง
    https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
    โปรโตคอลหลักถูกคิดขึ้นในยุคที่การส่งข้อมูล 1 ไบต์ผ่านลิงก์ดาวเทียมมีค่าใช้จ่าย 1 ดอลลาร์ จึง มีประสิทธิภาพ อย่างไม่น่าเชื่อและ implement ได้ง่ายด้วย

  • ครั้งหนึ่งในอดีต พอร์ตเดียวที่ใช้ได้ผ่าน firewall ของลูกค้าคือ MQTT 1883 เท่านั้น
    เพราะเขารับข้อมูลเซนเซอร์กันแบบนั้น และไม่ว่าจะขอยังไงก็ไม่ยอมเปิดพอร์ตอื่นให้ เลยทำ real-time TCP wrapper บน MQTT เพื่อเลี่ยงข้อจำกัด
    TCP daemon แบบ multithread ในเครื่อง local จะฟัง request ขาออกจากพอร์ตหนึ่ง ห่อด้วย MQTT แล้ว publish ไปยัง topic เฉพาะ ส่วน daemon ฝั่งเซิร์ฟเวอร์จะตรวจจับ topic นั้น แกะออก แล้วส่งต่อไปยัง server process
    จากมุมมองของเครื่องลูกค้า มันดูเหมือนสร้างการเชื่อมต่อ TCP แบบ real-time ไปยังเซิร์ฟเวอร์ของเรา แต่ตรงกลางมี MQTT wrapper แปลก ๆ ที่มองไม่เห็นคั่นอยู่
    พอมันทำงานแล้วก็ดูสง่างามดี แต่การ debug นั้นทรมานจริง ๆ และต้องผ่านทางตันหลายครั้ง กว่าจะประกอบทุกอย่างให้เข้าที่ได้ใช้เวลาหลายเดือน

    • เคยทำงานในที่ที่ถ้า เลี่ยงกฎ firewall แบบนี้อาจโดนไล่ออกได้ด้วย
      เดี๋ยวนี้สถานการณ์ที่ทำอะไรไม่ได้ ต้องนั่งว่าง ๆ อยู่เฉย ๆ ถูกเรียกว่า “ปล่อยให้ process ทำงานไป”
    • โดยพื้นฐานแล้วก็เหมือน implement โปรโตคอล MQTT-Sockets และด้วยสิ่งนั้นก็น่าจะเชื่อมต่อไปยัง WebSockets server อีกฝั่งได้ด้วย

  • เรื่องน่าสนุกคือ Boost ไลบรารี C++ ที่โด่งดังที่สุด กำลังรีวิวว่าจะรวม implementation async-mqtt5 (https://github.com/mireo/async-mqtt5) เป็น Boost.MQTT ในช่วงเวลาเดียวกัน: https://lists.boost.org/Archives/boost/2024/10/index.php

    • สงสัยว่าทุกวันนี้ในโปรเจกต์ใหม่ ๆ คนยังเลือก Boost กันอยู่ไหม
      จากประสบการณ์ที่ได้ยินมา การนำมาใช้ส่วนใหญ่อยู่ในยุค 2000s และต้น 2010s มาก ๆ คือก่อนที่ทุกคนจะบังคับใช้ C++0x/C++11 และทุกวันนี้เห็นไม่บ่อยนัก
      boost.org เหมือนการเดินทางย้อนเวลา หน้าตายังเหมือนที่จำได้ราวปี 2008 ทุกอย่าง รวมถึงปุ่ม “Get Boost” ที่ทำเป็นภาพตัดต่อบนปุ่มหยุดฉุกเฉินก็ยังอยู่เหมือนเดิม

  • MQTT เป็นโปรโตคอลเล็ก ๆ ที่ดีจริง ๆ ไม่ใช่แค่ “เล็กพอ” สำหรับใช้กับโปรเจกต์งานอดิเรก แต่ยัง scale ได้พอจะใช้กับของอย่าง Facebook Messenger ด้วย
    [1]: https://engineering.fb.com/2011/08/12/android/building-faceb...

  • การโฆษณาว่า MQTT เบาและมีประสิทธิภาพนั้นไม่ค่อยทำให้ผมคล้อยตามได้
    สุดท้ายก็แค่ใช้ TCP/IP เท่านั้น และตามมาตรฐานในยุคนั้นอาจถือว่าพิเศษเมื่อเทียบกัน แต่ผมไม่เคยเห็นหลักฐานจริงที่สนับสนุนคำกล่าวอ้างแบบนั้น นอกจากการอวดซ้ำ ๆ
    ข้อดีคือเป็นมาตรฐาน จึงเชื่อมต่อกับอุปกรณ์สำเร็จรูปที่รองรับได้ แต่ผมก็ยังเห็นว่ามีตัวเลือกที่ดีกว่าสำหรับการ publish/subscribe หรือคิวข้อความ โดยเฉพาะถ้าต้องการ failover ฝั่ง consumer

    • อยากรู้ว่าตัวเลือกที่ดีกว่านั้นคืออะไร
      ข้อดีของ MQTT และเป็นจุดที่ implementation แบบ publish/subscribe แทบทั้งหมดที่ผมเคยเห็นทำผิด คือโครงสร้างข้อมูลหลักของ MQTT ไม่ใช่คิวหรือ topic แต่เป็น ไคลเอนต์ที่ subscribe
      ดังนั้นจึงสามารถแมปพื้นที่ address space ที่ใหญ่เท่าไรก็ได้ตามต้องการเข้ากับ topic tree ได้ topic tree จะมี endpoint เป็นล้านล้านจุดก็ได้ และถ้าต้องการ แม้แต่บน embedded server ก็สามารถมี endpoint หนึ่งจุดสำหรับทุก IPv6 address ได้
      เมื่อ topic tree มีรายละเอียดมาก ก็ทำให้การ subscribe เลือกเฉพาะได้เท่าที่ต้องการ และเซิร์ฟเวอร์ก็ยังทำงานได้เร็วโดยใช้ทรัพยากรน้อย
    • อยากรู้จริง ๆ ว่า ทางเลือก ที่ดีกว่าสำหรับ publish/subscribe และคิวข้อความคืออะไร

  • ใช้ MQTT ในคลาส IoT มาหลายปีแล้ว และพิสูจน์แล้วว่าเป็น เครื่องมือที่ใช้งานได้หลากหลายมาก
    การที่รองรับผ่าน WebSocket ด้วยก็สะดวก

  • ในโปรเจกต์ embedded system ล่าสุด ผมใช้ MQTT เป็น ระบบรับส่งข้อความระหว่างโปรเซส ซึ่งค่อนข้างสนุก
    broker กับ client รันอยู่บนเครื่องเดียวกัน
    ถ้าต้อง sniff หรือ debug อะไร ก็แค่ต่ออุปกรณ์เข้ากับเครือข่าย แล้วใช้ MQTT Explorer บันทึกหรือ inject ข้อความได้ ง่ายมาก
    ยังเปิดพอร์ตออกนอก LAN เพื่อให้เพื่อนร่วมงานที่ทำงานจากระยะไกลเข้ามาจัดการระบบได้ด้วย

    • ไม่ค่อยเห็นการใช้แบบนี้มากนัก แต่ดูเหมือนจะมีคุณสมบัติที่น่าพึงประสงค์อยู่
      สิ่งที่กังวลที่สุดเวลาใช้เป็นส่วนประกอบของระบบคือ การรับประกันความทนทานของข้อมูล และผมไม่ค่อยมั่นใจว่า implementation ของ broker จะไม่ทำข้อมูลหาย
    • เราใช้ ZeroMQ สำหรับงานลักษณะนี้ ไม่ต้องมี broker
    • ในกรณีนี้ ZeroMQ น่าจะเป็นทางเลือกได้ไหม?