Complete the experimental CoAP over TCP implementation

[boaks]

In the discussion about the features for a 3.0 release, one larger topic was to completion of the RFC 8323 implementation.

The current experimental implementation is based on a early version of that RFC.
Mainly left to implement is the closing or dropping of connections and the signaling.
In my experience, the "tls resumption" was somehow very strict.
The cipher-suite provided by the jvm are without PSK and RPK, at least in java 8.
(Some has used bouncy castle for that).

[rogierc]

What is considered a must have before tcp_experimental_features branch could be merged with master?
Is that closing or dropping of connections and the signaling only?

[boaks]

The experimental branch contains only the BERT extension.
There is no pre-requirement from my point.
AFAIK, @sbernard31 didn't object to include the BERT support into the master.

[boaks]

With PR #1507 the tcp_experimental_features branch will be merged. (More precise, the BERT feature, based on a static configuration. According RFC 8323 it's also dynamically negotiated.)
If you want to contribute some more tcp-feature in order to get it more completed and less experimental, you're very welcome. Maybe a simple jdk-only tcp-client-connector implementation will also be not too bad.

[boaks]

Just to mention:
I plan to release 3.0.0-RC1 in August. If someone wants to work on this, please do so.
Otherwise I think, it's better to close it, though no one seems to has the time to work on it.

[sbernard31]

I never play with coap+tcp.
But I still have in mind the idea to try it and see what could mean adding coap+tcp support to Leshan.
I feel that providing at least an experimental support in Leshan would be good.
But I don't know :

• When I will be able to do that
• How this would be impacting for Leshan. (e.g. Should I make this kind of dependencies optional ?, I have some concern about TLS which could have less suitable API than Scandium one)
• What is currently missing in californium TCP ?

I also feel that :

a simple jdk-only tcp-client-connector implementation will also be not too bad.

I'm pretty sure that August is a too short timing for this anyway. So If changes are needed maybe in a 3.1 or 4.0 ?

[boaks]

I feel that providing at least an experimental support in Leshan would be good.

That should be not that hard, just use it, as it is.

What is currently missing in californium TCP ?

I don't know, I didn't study RFC8323 in the last years.

Generally, I don't plan to remove something. But I also don't plan to improve the implementation and make it compliant to that RFC.

I'm pretty sure that August is a too short timing for this anyway.

FMPOV, that should not take too much more time than a week. No one spent the time in the last months, therefore I consider, no one will do so in the next months also. if that changes, then maybe in 3.x or a 4.0.

[boaks]

I don't consider someone working on this.
If the interest changes, let us know.

[sbernard31]

As I currently try to implement a first experimental version of LWM2M over CoAP over TCP based on Californium. (eclipse-leshan/leshan#1047)
I would like to have a Californium ressource which lists missing (optional and mandatory part) of CoAP over TCP RFC-8323, so I could redirect Leshan user to it.

Should I :

1. reuse this issue ?
2. create a new one ?
3. create a wiki page ?

[sbernard31]

@boaks ping (just in case you missed ☝️)

[boaks]

I'm OK with all.

[sbernard31]

I created a wiki page : https://github.com/eclipse-californium/californium/wiki/CoAP-over-TCP with my current knowledge.

[boaks]

Great!

Just some remarks:

Observing Resource

If I remember it well, it requires also to cancel the observes, when the connection is closed.

The idea about having a TCP connector based on JDK only was raised by the past but there is nothing like this for now.

The idea was mainly intended for clients. For server I consider netty.io as a very well communication library.

Note about CCM_8 mandatory cipher suite

FMPOV, CCM_8 saves 8 bytes per record. In many cases, that doesn't matter. And those cases, where it matters, may require UDP as well. So for now, I would just go with the supported cipher suites from the JDK/netty. From the past I remember, that using "bouncy castle" as JCE may also help.

[boaks]

Let me add.

Note about CCM_8 mandatory cipher suite

It's for sure possible, to extend Scandium to be used for TLS as well.
But for me the very first step is to see, if CoAP over TCP works and comes with the expected benefits. At least FMPOV, that should be possible with the x509 cipher suites available in the JCE. Many device stacks are just using mbedtls, and many of them supports the cipher suite selections of the hyper scalers (see e-mail from T. Fossati ). So at least to start, that is not a bad choice.

[sbernard31]

I tried to update the page with your remarks.

[boaks]

The wiki page "LGTM" :-).