Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a ThingMonk 2014: How To Improve On MQTT 3.1.1
Similar a ThingMonk 2014: How To Improve On MQTT 3.1.1 (20)
Más de kellogh
Último
Último (20)
ThingMonk 2014: How To Improve On MQTT 3.1.1
- 1. HOW TO IMPROVE ON MQTT 3.1.1 Tim Kellogg @kellogh MQTT: An Implementor’s Perspective AOL Keywords: vasters mqtt
- 2. MQTT Servers Wired Networks Vertically scaled
- 3. fuel loca-tion Funnel Protocol temp Kafka | AMQP | HTTP
- 4. MQTT “Uptime” isn’t straightforward “Exactly Once” Violates CAP Security Problems • Retained messages • Provenance Error Handling
- 5. CAP Theorem Availability Network Partitions Consistency CP AP
- 6. CAP Theorem Availability Partition Tolerance Guaranteed In-Order Delivery CP AP
- 7. Subscriber dies prematurely Receive • Via QoS 2 Do Work • Not idempotent work • Duplicate message would cause errors Crash • ACK isn’t sent
- 8. Subscriber dies prematurely (2) Receive • Via QoS 2 ACK • Auto-acknowledge Crash • Before work is done
- 9. MQTT Recommendations Message Dedup • Have clients implement “QoS 2” via QoS 1 Token-based Security Provenance story Metadata about messages Error codes
- 10. CoAP-PubSub Resource Directory Garbage Collection Polling Allowed Retained Messages Error Codes
- 11. QUESTIONS? @kellogh app.thingfabric.com mqtt.io – No Bullshit, Just MQTT™ coap.io – No Bullshit, Just CoAP-PubSub™
Notas del editor
- MQTT was created in 1999 when “scaling” meant “scaling vertically”. MQTT scales great vertically, but lots of issues when scaling horizontally.
- MQTT works great when used as a funnel protocol, piping data into a more appropriate mechanism for intra-cloud communication. Still doesn’t do a great job of catering to constrained sensors/actuators
- Uptime – inconsistent perception of “available” between client and broker. The broker may be available but not accessible due to stale DNS entries (assuming DNS load balancing) Exactly-once – More about this on next slides Security– Infinite topics can be stuffed with retained messages, causing possible DoS. Lack of proper errors makes it difficult to communicate authorization and rate-limits. Provenance – Either end-to-end security (and give up pub-sub features) or use a hacky topic-level ACL implementation. Error handling – Can’t communicate rate limits, authorization errors, message size errors, etc.
- 2-byte identifier needs to be unique across cluster, not big enough Takes client failures into account, but mostly ignores server failures and auto-failover