Experiments some LwM2mEndpoint abstraction.

[sbernard31]

This not even a draft but more some experimentation about finding a way to be able to :

• remove strong californium dependencies. (cf should only be used to implement an endpoints provider)
• being able to add any number of endpoints. (not just 1 coap and 1 coaps)
• being able to add more transport layer.
• being able to have different implementation of same transport layer. (could be different underlying library or just same library with different configuration)

This is a work in progress and for now code is really crappy. But it aims to explore, find ideas or detect issue about this.

For now, I targeted the LWM2M server.

[sbernard31]

I have a crappy working LeshanServer2 which does not depend anymore to Californium. I think this give a good idea about which kind of abstraction we need.

The coapAPI() from LeshanServer was removed and I don't know for now if we will reintroduce it and how this should look like.

The observation part are the most problematic changes. For now I will focus on making it works and we will see in a second time if we can improve the californium integration.

The RedisRegistrationStore is not supported and if we re-implement it I guess it will not be backward compatible.

About LwM2mEndpointProvider I was thinking in a first time that this could be something which could be reused by server, bsserver and client. But finally I'm not so sure. So I will probably first try to make it work with not so common code and then I will see if I can make a more generic abstraction. (My current bet this will not be possible ...)

I'm not sure what should be the next step :

1. either experiment bootstrap server and client
2. or try to implement the server in a more proper way.

For 2.), I need a feature freeze and this should probably wait after next milestone release 2.0.0-M7.

[sbernard31]

I rebase this on master. And move forward a little bit more for the LWM2M server side.

Doing that I find an OSCORE blocker issue (https://github.com/eclipse/leshan/issues/1231#issuecomment-1199061571), AFIAK without a fix in californium OSCORE should not work anymore in this branch.

[sbernard31]

I improve this a bit more :

• I remove all the class named ClazzName2 (like LeshanServer2, LeshanBuilderServer2, ...)
• I make the code build again. (lot of test was adapted but still some tests just commented because they probably need a total rewrite :grimacing:)

I think about a new architecture design : #1295.

I need to think more about next steps. (out of office next 2 weeks)

[sbernard31]

The API in this PR looks like this :

// You create your LeshanServer with the builde like before
LeshanServerBuilder builder = new LeshanServerBuilder();

// But builder does not allow to configure any details about transport layer anymore
// instead you need to provide 1 LwM2mEndpointsProvider (API need to be change to support several provider)
// LwM2mEndpointsProvider will provide 1 or several LwM2mEndpoint

// For Californium (coap/coaps), Endpoint Provider API looks like this : 
// --------------------------------------------------------
CaliforniumEndpointsProvider.Builder endpointsBuilder = new CaliforniumEndpointsProvider.Builder(
                new CoapProtocolProvider(), new CoapsProtocolProvider());

 // Change Californium configuration : 
Configuration serverCoapConfig = endpointsBuilder.createDefaultCoapServerConfiguration();
serverCoapConfig.set(DtlsConfig.DTLS_RECOMMENDED_CIPHER_SUITES_ONLY,  true);
endpointsBuilder.setCoapServerConfiguration(serverCoapConfig);

// By default the Californium Builder will create 1 endpoint by protocolProvider
// But you can create it manually like this : 
endpointsBuilder.addEndpoint(new InetSocketAddress(0), Protocol.COAP);
endpointsBuilder.addEndpoint(new InetSocketAddress(0), Protocol.COAPS);

// then add the endpoints provider to LeshanServerBuilder
builder.setEndpointProvider(endpointsBuilder.build());

[sbernard31]

I push some experimental code about abstraction at client side.

The API is near than one used at server side bu as expected (https://github.com/eclipse/leshan/pull/1220#issuecomment-1068986342) I'm afraid it will be not near enough to allow real code factorization .. :disappointed:

Like for Server side, the observation part is probably the most tricky one and will maybe not fit well with other protocol/library than CoAP/Californium.

Next step I will try to create an experimental coap+tcp endpoint.

[sbernard31]

I created a POC about coap over tcp support at #1312 which helps me to raise/fix some design issue I missed at first try.

I think next step should be to try to implement a more clean version of the endpoint abstraction at server side :thinking:

Of course if anybody looks/experiment this PR on its side, do not hesitate to share any thoughts/feedback :pray:

[sbernard31]

I think next step should be to try to implement a more clean version of the endpoint abstraction at server side

This is done at #1318.

[sbernard31]

I will now try to go with a cleaner version at client side.

[sbernard31]

I will now try to go with a cleaner version at client side.

This is done at #1323

So I close this PR which is obsolete now.