General discussion / feedback from Leshan Team

[sbernard31]

Summary :

Leshan is a java implementation of LWM2M and until now it was strictly based on californium.
Recently we did massive changes to abstract transport Layer. (See : eclipse-leshan/leshan#1025)

Now to test this abstraction we are playing with java-coap (See : eclipse-leshan/leshan#1373)

I will use this general issue to ask questions and provides feedback about it.

Some questions :

1. In californium, there is a endpoint concept. If I simplify the concept a lot this is the socket where message are received. In californium a coap server can have several endpoints. If I understand java-coap correctly, 1 server is only associated to 1 socket right ?

2. is there a way to check if a message (request or response) is CON or not ? something like : if (!CON.equals(coapRequest.getType()))

3. is there a way to set a message (request or response) as CON ? something like : coapRequest.setConfirmable(true);

4. is there a way to execute code after the message( mainly needed for response) is sent ? Maybe a callback once the message is sent ?

5. Patch, IPatch and Fetch seems not implemented ? correct ? is it planned to implement it ? (I think we mainly need Ipatch and fetch for lwm2m composite operation)

6. If you are curious you can have a look at how we are using java-coap, See : https://github.com/eclipse/leshan/compare/5b0b66fa675da2ad9224d15e828036d0c06d0f40
   E.g : I created a kind of ResourceService to be able to add some Resource (see RegistrationResource), I don't know if this is a good idea or if this could give you some hint about changing java-coap API ? 🤷‍♂️

(more question is coming soon 😁 )

[szysas]

Some answers

1. In java-coap, socket is abstracted with CoapTransport interface. If you need to use multiple sockets, then it can be done by creating CoapTransport adapter that will proxy to multiple, underlying instances. Out of curiosity, what is the use case when you want to receive from multiple sockets?
2. At the moment there is no way to check it if incoming request or response was NON. If needed this info can be easily added to TransportContext (lets create separate ticket).
3. By default all outgoing requests are CON, to change it to NON one need to set it in TransportContext, for example:
   https://github.com/open-coap/java-coap/blob/master/coap-core/src/test/java/com/mbed/coap/server/messaging/ExchangeFilterTest.java#L105
4. Not sure if I get you point, but you could wrap CoapTransport class and overwrite sendPacke method, there you could add callback to CompletableFuture.
5. Yes, it is planned.
6. Thanks for link, I will have a look.

[sbernard31]

thx 🙏

1. I don't know if I really need to have several socket by coapserver 😬. What I know for sure is that 1 LWM2M server should have several socket open with different protocol. n socket for coap, n socket for coaps, n socket for coap+tcp etc etc... This is just different way for a client to connect/communicate to a server. With Californium I create 1 coap-server with several endpoints. And as I have Californium design/API in mind, I tried to do the same with java-coap... But maybe I should just create several coapserver ?

2. Being able to check if a message (request/response) is a CON ? #29 I created the ticket but no urgency to work on it. Maybe better to first identify all problems :) (unless you're sure you want to add it to java-coap)

3. I will look at this.

4. I will try it.

5. Good to know.

6. ⚠️ this draft code not so clean. (do not hesitate to ask question if you see something not clear)

[szysas]

1. I think the only way would be to create multiple CoapServers, or on runtime client can create the one that is needed.

[sbernard31]

Some more questions about observe. I think this will be one of the big part.
Considering observe, a LWM2M server acts as a CoAP client (it sends request and receive notifications)

o1. I find API to send the observe request but didn't find how to get notification (I guess I should use ObservationConsumer but I'm not sure how)

o2. Leshan server based on Californium is able to persists "Observation", so if the server reboots no need to resent a new Observe request to new handle notification. Do you think this is doable with java-coap ? (if yes, could you share some hint)

[sbernard31]

I added a TokenGenerator to my experimentation, for now I go with a "not so java-coap" spirit way. (See eclipse-leshan/leshan@914f0d4). I guess it's OK for our POC.

But just by curiosity, reading #24 (comment), I understand there is maybe a more elegant way to do with filter ?

I try to investigate a bit but I'm not sure to find how I should add a filter to my client which I created like this CoapClient coapClient = CoapClientBuilder.clientFor(destination.getIdentity().getPeerAddress(), coapServer);

I guess that I should customize server.clientService() ? so maybe I need to create CoapClient without using Builder ?
Or maybe there is a way to customize clientService when I create coapServer but looking at the builder I didn't find anything.

I see there is an MIDSupplier but not a Token one.

I also maybe find a typo in coap server should inboundService be called outboundService ?

[szysas]

o1. To receive notifications, you could something like this:

        CoapClient client = CoapClientBuilder
                .newBuilder(new InetSocketAddress("localhost", 5683))
                .build();


        Function<CoapResponse, Boolean> consumer = coapResponse -> {
            System.out.println(coapResponse);
            return true; // return false to terminate observation
        };
        // send request to observe resource, observations will be handled in consumer callback
        CompletableFuture<CoapResponse> resp3 = client.observe("/sensors/temperature", consumer);

Note that this sets separate callback per observation relation.
I'm thinking to simplify it and set one observation consumer in CoapClientBuilder, what do you think?

o2. Currently that is not possible. How important is that feature for integration with Leshan?

[szysas]

Related to TokenGenerator, yes, it would be more 'elegant' and testable to create a filter. However I noticed that there is a missing method in builder class to add addition filters. I will try to improve it.

[szysas]

I also maybe find a type in coap server should inboundService be called outboundService ?

You're correct, thanks for pointing this out.

[sbernard31]

o1. I will try to play with your example then I let you know if 1 observation consumer seems better to me.

o2. It seems that users like observe feature but me not that much 😁 ... I try to rather encourage to use LWM2M Send Opeation which is a most simple alternative.
Why I don't like it ? because we faced lot of issues with observe until now. If you're curious you could have a look at : https://github.com/eclipse/leshan/wiki/LWM2M-Observe
So don't worry, I will be very surprised if java-coap fully support our needs out of the box concerning observe.

Currently that is not possible.

Maybe, it makes sense that some implementation support to persist observe relation and some others don't ? 🤔
So we could have a coap(s) support based on californium with persisted observation and coap(s)/coap(s)-tcp support based on java-coap without it ?
I need to check if I can modify Leshan in that way.

How important is that feature for integration with Leshan?

For some use case this could be very important. Without going too deep in the details. I guess when you create a LWM2M server based on Leshan and you manage lot of clients in production with lot of Observe Relation. When you reboot your server, this will be an issue to resend all observe requests. (For sure at Sierra, we need it but at least at short/mid term we will still use Californium and Scandium for coap/coaps in production)

[szysas]

I could not agree more with your finding about observe.

Related to storing observation relations, it comes down not only to store Token->UriPath but also IP address... which is very fragile device association because those will change (NAT).
Anyway, at least for that reason we would need to have single a single observation consumer.

[sbernard31]

Thats seems to confirm that implementers don't like so much "Observe" where users like it 😅

Related to storing observation relations, it comes down not only to store Token->UriPath but also IP address...

Ideally even more than a IP address, we find that to really make it work, it's better to store a kind of peer identify which are not the same depending of transport used or/and use cases.
(coap => peer address / dtls => could be a connection Id or a psk identity or a public key .... / coap+tcp => a tcp connection ?)

About o2) I just realize that I talk only about persisting observations but actually this is more than that...
Most of people who use Leshan in a production server want to be able to launch it in a cluster and so observation relation must be shared between all instance of the cluster. Currently in Californium this is achieve with a ObservationStore interface.

Let me know, if this is something you would "like" we explore together (first just by talking about it) or if you are too traumatized by "observe" feature 😁

[sbernard31]

In com.mbed.coap.packet.Code, should it be ?

     C201_CREATED(2, 01, 201),
-    C202_DELETED(2, 02, 200),
+    C202_DELETED(2, 02, 202),
-    C203_VALID(2, 03, 200),
+    C203_VALID(2, 03, 203),
-    C204_CHANGED(2, 04, 200),
+    C204_CHANGED(2, 04, 204),
-    C205_CONTENT(2, 05, 200),
+    C205_CONTENT(2, 05, 205),

[szysas]

No, third parameter is HTTP status code.