Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2m-iwg] TR : [core] CoAP tutorial 
Hi Phil, 

At the beginning we though to use Hessian which was an already existing binary serialization protocol [1]. The main (if only) advantage if using a binary protocol is bandwidth efficiency. After a while, for different reasons (IP not clear, the fact that Hessian dev seemed not very active, un optimized use cases, ...) it was decided to better exploit the binary serialization for the use case we wanted to optimize. Bysant was born. All in all, writing bytes in a stream can be done in infinitely different ways. The fact that Bysant is Yet Another Binary Serialization Protocol need to be juxtaposed to the fact that its complexity is rather low.
But that is not the best part. Serialization is one aspect of M3DA. But the protocol was designed into different layers so that Serialization and Application layers are independent. Said differently you could use M3DA with a different serialization layer. And indeed we did some POC running M3DA with JSON, Hessian, etc.
Your point is valid though. We need to verify, being an OpenSource component, that the choices that were made before are still good or valid today (M3DA was designed some time ago, when we were not OpenSource). Or provide other serialization as the standard distribution.

Thx,
Cuero


[1] http://hessian.caucho.com/


-----Original Message-----
From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Philip Lombardi
Sent: Monday, May 20, 2013 4:01 PM
To: m2m Industry Working Group
Subject: Re: [m2m-iwg] TR : [core] CoAP tutorial

Benjamin,

I have been quietly following your M3DA protocol for a bit now, and perhaps I missed it somewhere, but I still do not understand the reason for introducing Yet Another Binary Serialization Format. Why did you not choose one of the well-known existing ones such as Protocol Buffers, ASN.1, MessagePack or BSON. Is there any information out there about the supposed compression superiority of Bysant serialization compared to those binary formats? When you say Bysant is more efficient, what are you referring to exactly? Speed at which it can be encoded and decoded on embedded devices or size of the data after encoding? Introducing a new poorly-understood (and I mean that fully in the context of experience developers have with other more well-known formats and not design) data serialization format for use in the M2M space seems... unnecessary and only makes the barrier to connect devices higher and harder to reach. Not to mention all of those other existing serialization protocols have a wealth of libraries in existence for serializing, de-serializing and debugging messages encoded in the respective format as well as lots of real-world use and testing. 

Cheers,
Phil

-----Original Message-----
From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Benjamin Cabé
Sent: Monday, May 20, 2013 2:11 AM
To: m2m Industry Working Group
Subject: Re: [m2m-iwg] TR : [core] CoAP tutorial

Mike,

M3DA and LWM2M basically serve similar purposes, in that they can both be used for Device Management _and_ Application data.

LWM2M comes from a Device Management history, and therefore has the
advantage of supporting well all the use cases that OMA-DM supports. 	
When it comes to Application Data, M3DA has been designed with M2M in mind right from the beginning, and brings a security model with a smaller footprint (CPU and bandwidth) and is more efficient in terms of bandwidth use thanks to the Bysant serialization protocol (LW suggests the use of binary TLV or JSON thus arguably isn't as efficient).
Being based on CoAP, LWM2M allows unicast and multicast, when M3DA only allows 1-to-1 communication between two nodes. This is BTW also one of the main difference between MQTT and M3DA which makes them target different use cases. 

Both CoAP and LWM2M look like an interesting addition to the set of protocols we support already at Eclipse M2M, especially with Ponte arriving.
It'd be interesting if one would contribute an open-source implementation of LWM2M, that could possibly be bridged to/from MQTT or M3DA thanks to PonteŠ Also, I believe that the experience of our group with MQTT and M3DA is a great opportunity for driving improvements in the CoAP and LWM2M specs.

Others mileage may vary and I'm keen to hear what other think.

Cheers,
Benjamin-- 






Le 19/05/13 23:18, « Mike Milinkovich » <mike.milinkovich@xxxxxxxxxxx> a écrit :

>Benjamin,
>
>Could you help me understand the differences between the M3DA and OMA 
>LWM2M protocols?
>
>Mike Milinkovich
>+1.613.220.3223
>mike.milinkovich@xxxxxxxxxxx
>
>On 2013-05-19, at 5:02 PM, Benjamin Cabé <bcabe@xxxxxxxxxxxxxxxxxx> wrote:
>
>> Hi,
>> 
>> You will find below the links to two interesting slide decks 
>>introducing CoAP and Lightweight M2M.
>> 
>> Benjamin-
>> 
>> ________________________________________
>> De : core-bounces@xxxxxxxx [core-bounces@xxxxxxxx] de la part de Zach 
>>Shelby [zach@xxxxxxxxxxxxx]  Date d'envoi : dimanche 19 mai 2013 22:14 
>>À : core@xxxxxxxx (core@xxxxxxxx)  Objet : [core] CoAP tutorial
>> 
>> Hi,
>> 
>> As we are completing publication of the CoAP RFC, it is a good time 
>>for the working group to help out with educating people about CoAP. I 
>>have posted my latest tutorials about CoAP and OMA Lightweight M2M on 
>>Slideshare, hopefully people find these useful:
>> 
>> http://www.slideshare.net/zdshelby/coap-tutorial
>> http://www.slideshare.net/zdshelby/oma-lightweightm2-mtutorial
>> 
>> If there are other tutorials, articles or other useful material out 
>>there, please let us know!
>> 
>> I also noticed we have a Wikipedia page, at least the list of 
>>implementations is pretty detailed. If someone could expand the 
>>technical description of the protocol that would be awesome:
>> 
>> http://en.wikipedia.org/wiki/Constrained_Application_Protocol
>> 
>> Regards,
>> Zach
>> 
>> --
>> Zach Shelby, Chief Nerd, Sensinode Ltd.
>> http://www.sensinode.com @SensinodeIoT
>> Mobile: +358 40 7796297
>> Twitter: @zach_shelby
>> LinkedIn: http://fi.linkedin.com/in/zachshelby
>> 6LoWPAN Book: http://6lowpan.net
>> 
>> 
>> 
>> 
>> _______________________________________________
>> core mailing list
>> core@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/core
>> _______________________________________________
>> m2m-iwg mailing list
>> m2m-iwg@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/m2m-iwg
>> 
>_______________________________________________
>m2m-iwg mailing list
>m2m-iwg@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/m2m-iwg

_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg

Back to the top