Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiments some LwM2mEndpoint abstraction. #1220

Closed
wants to merge 2 commits into from
Closed

Conversation

sbernard31
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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 (#1231 (comment)), AFIAK without a fix in californium OSCORE should not work anymore in this branch.

@sbernard31 sbernard31 force-pushed the lwm2m_endpoint branch 3 times, most recently from 4820a99 to bd74b88 Compare August 3, 2022 16:00
@sbernard31
Copy link
Contributor Author

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 😬)

I think about a new architecture design : #1295.

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

@sbernard31
Copy link
Contributor Author

sbernard31 commented Aug 5, 2022

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
Copy link
Contributor Author

I push some experimental code about abstraction at client side.

The API is near than one used at server side bu as expected (#1220 (comment)) I'm afraid it will be not near enough to allow real code factorization .. 😞

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
Copy link
Contributor Author

sbernard31 commented Sep 16, 2022

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 🤔

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

@sbernard31
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@sbernard31
Copy link
Contributor Author

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.

@sbernard31 sbernard31 closed this Oct 13, 2022
@sbernard31 sbernard31 deleted the lwm2m_endpoint branch January 26, 2023 16:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant