Internet of Things : protocols war !

8,801 views

Published on

A comparison between four of the main IoT protocols : HTTP, CoAP, MQTT and AMQP. The comparison is made with few "battles" on some "fields" like : implementation, communication pattern, data manipulation, security, reliability and quality of service.

Published in: Technology

Internet of Things : protocols war !

  1. 1. IoT protocols war ! Battles on the fields … Paolo Patierno Microsoft MVP Windows Embedded / IoT ppatierno@live.com @ppatierno
  2. 2. Senior Software Engineer (Ditron S.r.l.) Microsoft MVP Windows Embedded / IoT ”... constantly moving between the devices and the cloud ...” ”DotNetCampania” member http://dotnetcampania.org/blogs/paolopat/default.aspx “Embedded101” board of director member http://www.embedded101.com/Blogs/PaoloPatierno.aspx “TinyCLR.it” member http://www.tinyclr.it Linkedin http://it.linkedin.com/in/paolopatierno Who am I ? Contacts
  3. 3. IoT protocols introduction HTTP, CoAP, MQTT, AMQP battles on the fields ... implementation and weight data transfer and manipulation IoT communication patterns reliability and QoS security Agenda
  4. 4. IoT protocols landscape
  5. 5. IoT protocols trends
  6. 6. HTTP IETF standard (RFC 2616 is HTTP/1.1) CoAP IETF standard (RFC 7252) MQTT soon (end 2014 ?) OASIS standard AMQP OASIS and ISO 19464 standard (1.0) Standardization
  7. 7. Client/Server request/response HTTP : synchronous CoAP : (also) asynchronous HTTP is ASCII based CoAP is binary based Architecture : HTTP & CoAP Client Server
  8. 8. Broker and connected Clients broker receives subscriptions from clients on topics broker receives messages and forward them clients subscribe/publish on topics Brokers bridge configuration Architecture : MQTT
  9. 9. Architecture : AMQP (1.0) client producer (consumer) broker queue container containerconnection session link node node multiplexing frames on sessions and links transport indipendent brokered
  10. 10. HTTP client more complex (ASCII parser) more bytes to pay on data transfer connection oriented via TCP CoAP HTTP-like but binary connection less via UDP client more simple than HTTP “options” like HTTP headers (binary) Implementation & Weight
  11. 11. MQTT client simple to develop (spec about 70 pages) constrained devices (smallest packet 2 bytes) connection oriented via TCP AMQP client more complex connection oriented via TCP (with multiplexing) Implementation & Weight
  12. 12. HTTP & CoAP Content-Type based on MIME MQTT payload agnostic no data types no metadata any data format (text, binary, JSON, XML, BSON, ProtoBuf, ...) peer must agree on serialization/deserialization Data transport & manipulation
  13. 13. AMQP message header : system and custom/user properties body : opaque metadata data types system peers can use Content-Type and Content-Encoding filter on properties Data transport & manipulation
  14. 14. IoT communication patterns Telemetry Information flows from device to other systems for conveying status changes in the device Inquiries Requests from devices looking to gather required information or asking to initiate activities Commands Commands from other systems to a device or a group of devices to perform specific activities Notifications Information flows from other systems to a device (-group) for conveying status changes in the world 1:N 1:N
  15. 15. HTTP REST architecture for CRUD operations on resources CoAP REST architecture for CRUD operations on resources MQTT topics based AMQP distribution nodes (aka queues) based IoT communication patterns : resources
  16. 16. devices act as ”servers” URIs used for addressing resources schemes : http or coap addressing : <scheme>://<address>/<resource_path> verbs for CRUD operations POST, GET, PUT, DELETE CoAP discovery (CoRE Link format) “well known” path to get available resources HTTP & COAP : URIs
  17. 17. Topics for publish and subscribe hierarchical wildcards (# and +) ex. building1/+/room1, building1/floor1/room1/# MQTT : topics
  18. 18. queus for ... inbox : telemetry, inquiry (and command response) outbox : command, notifications (and inquiry response) AMQP : distribution nodes (aka queues) Device Backend inbox outbox
  19. 19. Telemetry : HTTP Device (client) System (server) HTTP PUT /<resource> (group_id, device_id, value) HTTP 200 OK Device (server) System (client) HTTP GET /<resource> HTTP 200 OK (<resource>) (long) polling
  20. 20. Telemetry : CoAP Device (server) System (client) CON GET /<resource> Observe: 0 Token: 0xAB ACK 2.05 Observe: 30 Token: 0xAB <resource>… /<resource> changed CON 2.05 Observe: 31 Token: 0xAB <resource>… ACK Token: 0xAB /<resource> changed CON 2.05 Observe: 32 Token: 0xAB <resource>… ACK Token: 0xAB RST Token: 0xAB ACK Token: 0xAB register deregister
  21. 21. Telemetry : MQTT Device Broker PUBLISH /$TEL/group_id/device_id/<resource> acknowledgement (based on QoS) PUBLISH /$TEL/group_id/device_id/<resource> acknowledgement (based on QoS) PUBLISH /$TEL/group_id/device_id/<resource> acknowledgement (based on QoS) * $TEL as base for topics not needed
  22. 22. Telemetry : AMQP Device Server transfer (<resource>) transfer (<resource>) transfer (<resource>) settlement (based on QoS) settlement (based on QoS) flow in_queue
  23. 23. HTTP more verbose (ASCII, headers, ...) for few data addressing problem (mobile roaming, NAT, ...) no QoS (based on TCP) CoAP “observer” pattern addressing problem (mobile roaming, NAT, ...) QoS with “confirmable” message or not Telemetry : summary
  24. 24. MQTT born for telemetry with “publish/subscribe” pattern no flow control for a lot of data at high rate QoS (at most once, at least once, exactly once) AMQP messages flow control for more & high rate data QoS (at most once, at least once, exactly once) Telemetry : summary
  25. 25. Inquiry : HTTP Device (client) System (server) HTTP GET /<info> HTTP 200 OK (<info>)
  26. 26. Inquiry : CoAP Device (client) System (server) CON [0x123] GET /<info> ACK [0x123] 2.05 Content <info>…
  27. 27. Inquiry : MQTT Device Broker SUBSCRIBE /$INQ/group_id/device_id/req_id PUBLISH /$INQ/<info> PUBLISH /$INQ/group_id/device_id/req_id acknowledgement (based on QoS) acknowledgement (based on QoS) inside publish inquiry payload from device * $INQ as base for topics not needed
  28. 28. Inquiry : AMQP Device Server transfer (<info>, replyTo, messageId) transfer (<info>, correlationId = messageId) settlement (based on QoS) settlement (based on QoS) in_queue out_queue
  29. 29. HTTP & CoAP request/response pattern MQTT no built in response path support needed to define a response topic pattern (over) group_id, device_id, req_id in custom format (as payload) AMQP built in response and correlation support “replyTo” and “correlationId” for request/response Inquiry : summary
  30. 30. Command : HTTP Device (server) System (client) HTTP POST /<cmd> HTTP 200 OK (<result>) (long) polling
  31. 31. Command : CoAP Device (server) System (client) CON [0x123] POST /<cmd> Token: 0xAB ACK [0x123] CON [0x7F2] 2.05 Content Token: 0xAB <result>… ACK [0x7F2] Too much time result
  32. 32. Command : MQTT Device Broker SUBSCRIBE /$CMD/group_id/device_id/<cmd> PUBLISH /$CMD/group_id/device_id/<cmd> PUBLISH /$CMD/group_id/device_id/<cmd>/req_id acknowledgement (based on QoS) acknowledgement (based on QoS) inside publish command payload from system * $CMD as base for topics not needed
  33. 33. Command : AMQP Device transfer (<cmd>, replyTo, messageId) transfer (<result>, correlationId = messageId) settlement (based on QoS) settlement (based on QoS) Serverin_queue out_queue
  34. 34. HTTP more verbose (ASCII, headers, ...) for few data addressing problem (mobile roaming, NAT, ...) no QoS (based on TCP) CoAP response after a while pattern addressing problem (mobile roaming, NAT, ...) QoS with “confirmable” message or not Command : summary
  35. 35. MQTT no built in result command path support needed to define a result topic pattern (over) addressing result (req_id) in custom payload if device is offline no TTL (Time To Live) for command old command could be delivered (if “retain” flag) new command could be lost (if not “retain” flag) commands are enqueued only if not “clean session” Command : summary
  36. 36. AMQP built in result and correlation support “replyTo” and “correlationId” for command/result if device is offline TTL (Time To Live) to avoid old command commands are enqueued Command : summary
  37. 37. Notification : HTTP Device (server) System (client) HTTP POST /<notify> (content) HTTP 200 OK
  38. 38. Notification : CoAP Device (server) System (client) CON [0x123] POST /<notify> (content) ACK [0x123]
  39. 39. Notification : MQTT Device Broker SUBSCRIBE /$NOT/<notify> PUBLISH /$NOT/<notify> acknowledgement (based on QoS) * $NOT as base for topics not needed
  40. 40. Notification : AMQP Device Server (out_queue) transfer (<notifiy>) settlement (based on QoS) transfer (<notify>) settlement (based on QoS) flow
  41. 41. HTTP more verbose (ASCII, headers, ...) for few data addressing problem (mobile roaming, NAT, ...) no QoS (based on TCP) CoAP addressing problem (mobile roaming, NAT, ...) QoS with “confirmable” message or not Notification : summary
  42. 42. MQTT born for notification with “publish/subscribe” pattern no flow control for a lot of data at high rate QoS (at most once, at least once, exactly once) AMQP messages flow control for more & high rate data QoS (at most once, at least once, exactly once) Notification : summary
  43. 43. HTTP basic & digest authentication HTTPS aka HTTP over SSL/TLS encryption only payload CoAP DTLS (Datagram TLS) encryption only payload Security
  44. 44. MQTT SSL/TLS username/password on connection encryption only payload AMQP SSL/TLS SASL (Simple Authentication and Security Protocol) encryption only payload Security
  45. 45. devices consider how much they are constrained network how much it is reliable do you pay for data bytes transferred ? message rate how many messages per second QoS needs Conclusions
  46. 46. security authenticity ? only signature confidentiality ? need encryption analysis & big data needs of the backend to process data self descriptive message with metadata ? raw data, more fast ? Conclusions
  47. 47. protocol choice depends on scenario some protocols have more features than other a complex system can use more protocols Conclusions
  48. 48. IoT/M2M Embedded101 free ebook : http://bit.ly/m2miotbook Subscribe! Blog : http://channel9.msdn.com/Blogs/Subscribe IBM redbook : http://www.redbooks.ibm.com/abstracts/sg248054.html IoT with Azure Service Bus : http://channel9.msdn.com/Events/Build/2014/3-635 Windows and Internet of Things : http://channel9.msdn.com/Events/Build/2014/2-511 MQTT Official web site : http://mqtt.org M2Mqtt project : http://www.m2mqtt.net Mosquitto : http://mosquitto.org HiveMQ : http://www.hivemq.com Eclipse IoT : http://iot.eclipse.org MQTT An implementer’s perspective : http://bit.ly/1koMZLF MQTT Another implementer’s perspective : http://bit.ly/1rHDnAN Resources
  49. 49. CoAP Coap Technology : http://coap.technology Official draft : https://datatracker.ietf.org/doc/draft-ietf-core-coap CoRE Link format : http://tools.ietf.org/html/rfc6690#section-3.1 CoAPSharp : http://www.coapsharp.com Copper : https://github.com/mkovatsc/Copper AMQP Official web site : http://www.amqp.org Microsoft Azure Service Bus : http://azure.microsoft.com/en-US/services/messaging/ AMQP.Net Lite : https://amqpnetlite.codeplex.com/ Qpid project : http://qpid.apache.org/ RabbitMQ : http://www.rabbitmq.com ActiveMQ : http://activemq.apache.org/ Resources
  50. 50. Thanks ! The End

×