Plans for Java-Coap implementation for COAPS/DTLS?

[Ozame]

Question

Recently the option of using Java-Coap instead of californium was added for CoAP over TCP(and TLS) communication. Are there plans on doing the same on DTLS side of things?

Especially the netty support within Java-Coap is something that would be nice to have, performance-wise.

[sbernard31]

Ideally this is something we would like to add but we don't know which DTLS stack we should use.

In fact this is a general Java issue, AFIAK there is not (D)TLS IoT oriented Java stack. I tried to summarize the issue there and try to find people to collectively find a solution but not a real success for now 😅

I guess if we would like to test that at short term we should try to use the mbedTLS wrapper used by java-coap.

Do you play with java-coap implementation ? I mean coap, coap+tcp or coaps+tcp support ? (I dodn't get any feedback since I deliver it, I guess people mainly use coaps over Californium.

[Ozame]

I see, sounds like a difficult problem. The future-proofness of mbedTLS in Java is certainly a question mark, though it seems there is an actual team behind java-coap, so they probably have ok resources for maintaining that.

I did not try out the tcp implementation, but I played around with the JavaCoapClientEndpointsProvider, and it seemed that without security, you were nicely able to just swap it in for the CaliforniumClientEndpointsProvider. Overall based on the quick peek around the java-coap, it seems like a a bit easier to understand library when compared to californium 😅

But yeah, mainly looking into that for the possible performance benefits over Californium. From Leshan point of view, do you think the COAPS version would require any other changes than handling the transport related stuff (channels, security settings etc.) with the CoapServer? I mean specifically in the leshan code, for example with observations/notifications and such?

For example, having something like this

public class JavaCoapsClientEndpointsProvider extends AbstractJavaCoapClientEndpointsProvider {

    private final EventLoopGroup eventLoopGroup = new NioEventLoopGroup(1, new DefaultThreadFactory("dtls-netty", true));
    private final DeviceSettings settings;

    public JavaCoapsClientEndpointsProvider(DeviceSettings settings) {
        super(Protocol.COAPS, "CoAPs over DTLS endpoint based on java-coap library", new DefaultCoapIdentityHandler());
        this.settings = settings;
    }

    @Override
    protected CoapServer createCoapServer(ServerInfo serverInfo, Service<CoapRequest, CoapResponse> router,
                                          List<Certificate> trustStore) {

        var transport = MbedtlsCoapTransport.of(...);

        return CoapServer.builder().outboundFilter(TokenGeneratorFilter.RANDOM)
                .transport(transport).route(router).build();
    }
}

[sbernard31]

Overall based on the quick peek around the java-coap, it seems like a a bit easier to understand library when compared to californium 😅

I have same feeling based on quick look too but in my experience it seems less feature complete than californium and maybe not yet fully production ready ?

From Leshan point of view, do you think the COAPS version would require any other changes than handling the transport related stuff (channels, security settings etc.) with the CoapServer? I mean specifically in the leshan code, for example with observations/notifications and such

Supposing :
we have a DTLS transport for java-coap (it seems it exists but I never tested it and so don't know the limitation (support of PSK ? RPK ? X509 ? Connection Id ? DTLS Session Resumption ? )

Then :
This should be mainly about setting :

• Security Setting from ServerSecurityInfo and securityStore
• Being able to extract client Identity from TransportContext and create TransportContext from Identity. (Missing peer identity/transport context checks ? open-coap/java-coap#84 this issue is a bit relative to that)

[boaks]

Especially the netty support within Java-Coap is something that would be nice to have, performance-wise.

Just for curiosity:
Do have performance numbers comparing a server using java-coap/netty vs. californium for plain coap?
Or do you expect only a better performance using dtls?
Or on a "multiple-client-application"?

[Ozame]

The aim here is to try improve the CPU / Thread usage in a multiple (tens of thousands) COAPS/DTLS client scenario. I was planning on updating the comparison with the californium and java-coap here once complete, hopefully in some time. Currently there's no plan to compare plain coap.

Hopefully we would be able to get some numbers with

1. Default californium setup,
2. Java-Coap setup,
3. Using Java 21 virtual threads with aforementioned.

Virtual threads would probably only make a difference when it comes to the RegistrationEngine threads, since based on the initial java-coap testing there will be 2 per client coming from there - RegistrationEngine thread, and some netty thread. So this we'll need to experiment a little with, using virtual threads/shared excecutors.

I'll update here once we have conducted the testing.

[boaks]

OK, if it's about the client side for load tests, then Californium hasn't been designed for that. I usually run something as 4 processes each 2000 clients and to get more sessions on the server side I reconnect 500 clients in and additional process after every 20 messages.

In that past we (Californium) considered to use nio for that, but as you may be aware, in the last years there haven't been too much interest in contributions. (Unfortunately, even if there has been a contribution as the improved TCP support, it was not possible for me to spend my time into review and maintaining that, therefore the leshan project addressed this topic in issue #1591).

For now (Californium 3.x) isn't tested with the newer java version, AFAIK the unit-test are broken but people are using a build without these tests, see Using Java 22.

It's long ago, that I did some performance tests. One topic for me was usually to focus of the stack. E.g. Californium is designed for high server load, e.g. a server with 4x3.5 GHz, 16 GB RAM executes 1.000.000 connected clients with about 50.000 msgs/s. So, if you test, I guess using a "mass client endpoint" is the one thing, but the server on the other side the other thing. I guess, it will payoff to measure the mass-client and server performance separately. And if you test the server-side, it's not only relevant, how that performs, when the clients are already connected, also the handshake performance and the load&handshake behavior is also of interest. Quite a lot of work.

I'm looking forward to your numbers.