| Re: [cf-dev] Serializing/de-serializing CoAPExchange object chain |
|
Hi Vinay,
forget what I said about the Endpoint interface. I was confusing it with the Connector interface defined by elemt
ent-connector... :-)
The Endpoint interface already is based on CoAP message objects. However, we would still need to figure out how to use this interface remotely in an efficient way ...
Kai
Von: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Hudalla Kai (INST/ESY1) [Kai.Hudalla@xxxxxxxxxxxx]
Gesendet: Freitag, 20. Mai 2016 10:13 An: Californium (Cf) developer discussions Betreff: Re: [cf-dev] Serializing/de-serializing CoAPExchange object chain Hi Vinay,
the way you describe it makes total sense to me. In fact, I have given this some thought as well during the last weeks. I can clearly see the advantage of being able to use a LWM2M server implementation, e.g. leshan, on top of arbitrary transports.
Currently, Californium's "northbound" API is the Endpoint interface which provides methods to send and receive RawData object instances which contain the (already serialized) CoAP messages. The problem with this approach AFAIK is that the serialization
of the CoAP messages to the wire protocol differs between UDP and the format proposed for CoAP-over-TCP.
I think it would therefore be better to let the Endpoint implementation (which is specific to a particular transport) do the de-/serialization and thus use CoAP Message objects as params in the Endpoint interface for exchanging data with the application
layer (instead of the RawData).
Of course we would then need to think about an appropriate (generic) serialization format for the CoAP objects that can be used for remote communication between the application layer (LWM2M in our case) and Californium. For that, I think a binary encoding
would be more appropriate instead of an XML based encoding for performance reasons ...
What do you think?
Kai
Von: cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Gajjala Vinay [Vinay.Gajjala@xxxxxxxxxxx]
Gesendet: Montag, 2. Mai 2016 19:40 An: Californium (Cf) developer discussions Betreff: Re: [cf-dev] Serializing/de-serializing CoAPExchange object chain Thank you for the response Kai.
The reason why I want to take this approach is
1. We support more than 2 dozen proprietary protocols in our platform 2. And we wanted to make the service which listens to the device traffic as light as possible. Mostly reading the device messages and forwarding these messages to the backend platform and sending messages to the device.
Additionally, since LwM2M uses CoAP for the transport as of today and may use MQTT or TCP in near future, I was thinking separating the concern of CoAP and LwM2M would be useful as we can use the same LwM2M implementation when LwM2M starts using MQTT/TCP as its transport.
Hope this makes sense.
Regards Vinay
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Hudalla Kai (INST/ESY1)
Hi Vinay,
seems like this question didn't receive much love (yet) ;-)
Personally, I do not think that distributing the LWM2M layer and CoAP layer to separate machines/processes is a very good idea. It somehow feels like splitting up a REST API implementation into a generic HTTP server process and a process implementing the REST API.
Adding a default constructor to CoAPExchange is certainly possible but I doubt that you will get happy with this approach.
Mit freundlichen Grüßen / Best regards Von:
cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Gajjala Vinay [Vinay.Gajjala@xxxxxxxxxxx] Hi
We use leshan and californium projects for implementing LwM2M in our platform. What I want to try is to decouple the CoAP and LwM2M implementation in Leshan.
For this I was trying to see if I can serialize the CoAPExchange object and send to over the network to the VM where the Leshan/LwM2M will be implemented.
The challenge I am facing is to serialize and de-serialize the CoAPExchange object as many of the classes in the object chain do not have the default constructor. BTW I am using a XML serialize.
Does anyone have a solution of how we can serialize/de-serialize objects whose classes do not implement the default constructor. After googling a bit , most of the solutions were around writing convertors, extending the classes or writing adapters. I do not want to write code for extending or adapting the classes as I will have to maintain this code whenever there are new version of CoAP.
Question: Can we add the default constructors to the CoAPExchange object chain so that marshaling and un-marshaling would be easy?
If we can add the default constructs or make the object serializable I can go ahead and contribute these changes to the repository.
Please advise.
Regards, Vinay
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either
whole or partial, is prohibited. This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. |