ฉันควรใช้ซ็อกเก็ตเว็บของ Mosquitto หรือเชื่อมต่อลูกค้าโดยตรงหรือไม่

11

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

หากฉันมีลูกค้าหลายรายในเครือข่าย (เช่นเซ็นเซอร์และแอคทูเอเตอร์ที่ใช้ไมโครคอนโทรลเลอร์เช่น Raspberry Pis) จะมีประโยชน์อย่างไรหากใช้ซ็อกเก็ตเว็บผ่านการเชื่อมต่อ TCP โดยตรง? ค่าใช้จ่ายของโปรโตคอลเว็บซ็อกเก็ตนั้นคุ้มค่าเมื่อคุณสื่อสารกับเบราว์เซอร์หรือไม่?

mqtt mosquitto web-sockets

— Aurora0001
แหล่งที่มา

1

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

— Mawg พูดว่าคืนสถานะโมนิก้า

1

@Mawg เซิร์ฟเวอร์จะเป็นนายหน้าของ Mosquitto MQTT แต่ฉันสามารถเลือกโปรโตคอลที่ฉันใช้สำหรับลูกค้าทั้งหมด (และ Mosquitto มีทั้งเว็บซ็อกเก็ตและการเชื่อมต่อ TCP โดยตรงซึ่งเป็นสาเหตุที่ฉันถาม)

— Aurora0001

1

ฉันคิดว่ามีความสับสนอยู่ที่นี่ ฉันเข้าใจว่า @ Auroa0001 หมายถึงอะไรโดย "direct TCP" กำลังใช้ MQTT ผ่าน TCP มากกว่า MQTT ผ่าน Websockets (... over TCP) ในทั้งสองกรณีมีไลบรารีให้ใช้งานดังนั้นไม่จำเป็นต้องเขียนโค้ดใด ๆ สำหรับซ็อกเก็ต

— ralight

@ ไฟต์ใช่นั่นคือความตั้งใจของฉันจริง ๆ เมื่อถามคำถาม คำตอบนั้นออกนอกลู่นอกทางดูเหมือนว่า

— Aurora0001

7

คำถามที่นี่ดูเหมือนจะเป็น "ฉันควรใช้ MQTT ผ่าน TCP หรือใช้ MQTT ผ่าน websockets (ซึ่งไปที่ TCP) ด้วย" กล่าวอีกนัยหนึ่งคือ "การห่อหุ้ม MQTT ในโปรโตคอล websockets เป็นความคิดที่ดีหรือไม่"

นี่คือ (เกือบ) ทั้งหมดลงในใบสมัครของคุณและไม่ว่าคุณต้องการการสนับสนุน websockets - อาจเป็นเพราะข้อความในเบราว์เซอร์หรือเหตุผลไฟร์วอลล์ หากคุณไม่สามารถเข้าถึงเซิร์ฟเวอร์ของคุณที่พอร์ต 1883 หรือดีกว่า 8883 สำหรับ MQTT แท้ๆเว็บโฮสติ้งอาจเป็นตัวเลือกที่ดีที่สุดของคุณ

เว็บซ็อกเก็ตต้องการแบนด์วิดท์เพิ่ม แต่สิ่งที่สำคัญสำหรับคุณคือสิ่งที่คุณสามารถตอบได้เท่านั้น

นอกจากนี้ยังเป็นที่น่าสังเกตว่าใน Mosquitto เวอร์ชันปัจจุบัน websockets ไม่ทำงานเท่าที่ควรเพื่อให้มีเวลาแฝงเพิ่มเติมเมื่อส่ง / รับข้อความ websockets นั่นคือสิ่งที่จะไม่เป็นปัญหาสำหรับรุ่นอนาคต

— ralight
แหล่งที่มา

7

เมื่อคุณสื่อสารภายในเครือข่ายของคุณเท่านั้น( อินทราเน็ต ) การใช้ TCP แบบปกติจะไม่เป็นไร แต่ถ้าคุณต้องเชื่อมต่อกับเซิร์ฟเวอร์อื่นปัญหาจะเกิดขึ้น

เพราะเซิร์ฟเวอร์ทันสมัยส่วนใหญ่ไม่อนุญาตให้ลูกค้าเชื่อมต่อผ่านพอร์ตสุ่ม พวกเขาอนุญาตให้เฉพาะบางพอร์ตเชื่อมต่อ นั่นคือทั้งหมดที่ ดังนั้นหากคุณต้องเชื่อมต่อกับเซิร์ฟเวอร์อื่น ๆ ควรใช้ websocket แทนการเชื่อมต่อ TCP อย่างแท้จริง

หากคุณกำลังพิจารณาค่าใช้จ่ายก็ไม่ได้ว่ามากที่ใหญ่กว่า คุณสามารถอ้างอิงบทความนี้หากคุณต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับค่าใช้จ่ายของ websocket

ในความเห็นส่วนตัวของฉันการใช้ websocket ดีกว่าเสมอยกเว้นคุณมีข้อกังวลใจ

— ThisaruG
แหล่งที่มา

2

ข้อผิดพลาด TCP และเว็บซ็อกเก็ตเป็นโปรโตคอล: tools.ietf.org/html/rfc6455นอกจากนี้ TCP IS เป็นซ็อกเก็ตที่ระดับต่ำ

— Goufalite

@ ThisaruGuruge ขอบคุณสำหรับคำตอบของคุณ - ในสถานการณ์ของฉันในคำถามฉันคิดว่าคุณจะเลือก TCP ผ่านทางเว็บซ็อกเก็ตตัดสินโดยคำตอบของคุณ? โดยเฉพาะอย่างยิ่งเนื่องจากเว็บซ็อกเก็ตส่วนใหญ่ได้รับการสนับสนุนโดยเบราว์เซอร์ดังนั้นจึงมีรหัสค่าใช้จ่ายที่จำเป็นต้องใช้กับเว็บซ็อกเก็ตผ่านซ็อกเก็ต TCP

— Aurora0001

1

"เซิร์ฟเวอร์สมัยใหม่ส่วนใหญ่ไม่อนุญาตให้ไคลเอนต์เชื่อมต่อผ่านพอร์ตสุ่ม" - เซิร์ฟเวอร์สามารถเลือกพอร์ตที่จะผูกกับ ( man7.org/linux/man-pages/man2/bind.2.html ) รวมทั้งไฟร์วอลล์สามารถ จำกัด อีกว่า อย่างไรก็ตามฉันไม่เห็นด้วยเมื่อคุณพูดว่า "ถ้าคุณต้องเชื่อมต่อกับเซิร์ฟเวอร์อื่นปัญหาจะเกิดขึ้น" กล่าวคำว่า " อาจเกิดขึ้น" แม้กระนั้นมันเป็นเรื่องของการกำหนดค่าซึ่งเว็บซ็อกเก็ตอาจจะทำง่ายกว่าซ็อกเก็ตดิบ

— Mawg กล่าวว่าจะคืนสถานะโมนิก้าเมื่อ

6

tl; dr - มักจะชอบไลบรารี่ฟรีที่จะเขียนโค้ดด้วยตัวคุณเอง (เว้นแต่คุณจะมีความต้องการมาก)

ฉันควรใช้ซ็อกเก็ตเว็บของ Mosquitto หรือเชื่อมต่อลูกค้าโดยตรงหรือไม่

สายอักขระยาวเท่าไหร่ (YMMV)

ฉันสามารถพูดได้เท่านั้นโดยทั่วไป แต่ฉันชอบไลบรารี่แบบห่อหุ้มมากกว่าซ็อกเก็ตแบบดิบ ๆ (หรือที่จริงแล้วคือการเขียนโค้ดอะไรก็ได้ที่ฉันสามารถหาได้ฟรีจากไลบรารี)

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

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

ค่าใช้จ่ายเพียงอย่างเดียวคือการเรียกใช้ฟังก์ชั่นหากคุณยอมรับว่าบรรณารักษ์ที่ดี (การจัดการข้อผิดพลาดการเก็บสายยาง & สิ่งที่คล้ายกัน) เป็นสิ่งที่คุณจะต้องใช้รหัสด้วยตัวเองเพื่อรับซอฟต์แวร์ที่ดีมีเสถียรภาพ

หากคุณกังวลเกี่ยวกับประสิทธิภาพการทำงานเพียงแค่สร้างโปรไฟล์ แต่ถ้าซ็อกเก็ตของคุณมีการใช้งานหลายร้อยครั้งต่อวินาทีฉันจะไม่รำคาญ

— Mawg กล่าวว่าคืนสถานะโมนิก้า
แหล่งที่มา

มีไลบรารีฟรีสำหรับการเชื่อมต่อ TCP และ (เว็บ) การเชื่อมต่อซ็อกเก็ตและทั้งคู่ต้องมีเหตุการณ์ "ได้รับข้อความ"

— Goufalite

2

OP ต้องการทราบว่าควรใช้ TCP หรือเว็บซ็อกเก็ตอย่างมีประสิทธิภาพหรือไม่และคุณพูดว่า "ใช้ไลบรารีนามธรรมเพื่อไม่ให้คุณรำคาญ" แน่นอน แต่อันไหน ใน C # มีไลบรารี TcpClient ใน System.Net.Sockets (ดี ... ) และห้องสมุด websocket ในแพ็คเกจ nuget (WebSocketSharp) ฉันยอมรับว่ามีไลบรารี่ MQTT ทั่วไปสำหรับทุกภาษา แต่ OP ต้องการควบคุมมันเพื่อเลือกโพรโทคอลที่ต้องใช้

— Goufalite