| Re: [m2m-iwg] COAP |
|
Completely agree, David! I’m envisioning something along the lines of websockets, with COAP-like payloads. That same pipe could be used to deliver change-based notifications (events,
data updates/reads/writes), request/response (service invocations). Event notifications and data updates are really just a special case of a service invocation. With some creativity, advanced functionality such as file transfers, chunked streams, and so
on can easily use the same mechanism. The content of the messages could be format agnostic (JSON or binary) though some work needs to be done on the content formats to enable interop. Not coincidentally, this is pretty much what we’re doing with our M2M
agents at ThingWorx today. We leverage HTTP/XMPP/WebSockets/TCP Sockets as the transport, effectively overlaying a REST-like API that can be invoked across a variety of transports and wire formats. From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx]
On Behalf Of Navarro, David I agree. But multiple protocols can be present on the M2M device. MQTT is a telemetry protocol. CoAP is ressource access protocol. LWM2M is a device management protocol
for instance. You don’t have one-size-fits-all. My point was simply that MQTT and CoAP may overlap but they do not compete. Regards, David Navarro From:
m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx]
On Behalf Of Rick Bullotta IMO, change and event-based notification will be a “must have” rather than a “nice-to-have” in current and future M2M applications and protocols. The “poll
to see if there are any changes” approach can often consume more device energy/communications bandwidth than change-based. Rick From:
m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx]
On Behalf Of Navarro, David Hi all, Please allow me to jump in. I’m working for Intel’s Opensource Technology Center and I participated in the development of OMA’s LWM2M (which relies on CoAP
as Julien said). I don’t think CoAP and MQTT are designed to answer the same use cases. MQTT (as I understand it) is all about publishing events with a subscribe mechanism.
CoAP is designed to be a replacement of HTTP in constrained environments. So even if CoAP features an Observe mechanism to be notified of value changes, it is not its main purpose and in this, it will be inferior to MQTT. And as an HTTP equivalent, CoAP makes
no assumption on the system topology. At the OMA, we choose to base LWM2M protocol on CoAP because it provides the core functionnalities of HTTP (GET, PUT, POST, DELETE commands, TLS security) in
a reduced footprint. The Observe mechanism is a nice-to-have feature but not essential in the LWM2M use-case. Regards, David Navarro From:
m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx]
On Behalf Of Matteo Collina The real difference between CoAP and MQTT is in how the notification of events works: In practice, it is the "gateway" or end-user that start observing for changes on the sensor. In MQTT, it is the other way around, it is the sensor that publishes stuff on a broker. However CoAP allows some true P2P communication between devices, which is not possible in a central system like MQTT. It has a real difference, and it may be the reason because it lacks adoption. I think deploying a central client-server system is much easier. Cheers, Matteo --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |