Experiment Transport layer with java-coap (fork)

[sbernard31]

To test new transport layer (#1025), we decide to experiment it a little with : java-coap (fork). (see : #1338)

This issue aims to centralize discussion about it.

[sbernard31]

@JaroslawLegierski I know you started to work about it, do you have any code to share.

You are working on client side right ?

[JaroslawLegierski]

You are working on client side right ?

Yes I have first version. I am currently able to perform registration, reg update, send data to server and deregister client.
The code doesn't look good (it's a terrible mess) - so I'd like to clean it a bit before sharing.

[sbernard31]

Ok I understand 🙂

[sbernard31]

@JaroslawLegierski do not hesitate to share even if code is not so good.

On my side, I will also begin to work on this as I'm a bit stuck :

• integrating transport layer abstraction : waiting for feedback from orange.
• refactor transport Layer Module following Transport Layer Module design. #1295 : try to get some feedback ?
• exploring coap+tcp : waiting for feedback from californium to move forward.

As you are on client, I will try to look at server side 🤔

[JaroslawLegierski]

OK the code won't be fully cleaned but I'd like to at least remove all failed "test blocks" from it. Unfortunately, I spend a some time on organizational tasks lately (e.g. point 1 from the list above ;-) and generally I'm a little late in this week.

[sbernard31]

(take your time, no pressure 😉)

[sbernard31]

I started to code something in java-coap branch.
This is not clean at all (very inspired from what I did with californium which is maybe not a good idea ? 🤔 )
This is not tested (not ever run) but I share it just in case it could helps. => a45f310

[JaroslawLegierski]

Please find my first tests results here . I started by modifying the existing cf-handling classes. It seems to me that Your approach (starting from the scratch) is definitely better because I'm still using cf classes and I still have a mess in the code.

[JaroslawLegierski]

Please find here new very initial version of leshan client using java-coap. This version has been developed based on template from you and should (finally) no longer contain the californium code. Thanks for your help and pointing me in the right direction ;-).

[sbernard31]

@JaroslawLegierski do not hesitate to share if you find anything smelly in new transport layer abstraction.

On my side, I moved forward about implementing Endpoints provider for server based on java-coap.
This is still available in java-coap branch. (commit 5b0b66f)
For now, I'm only focus on coap (not coaps).

I inspired myself from your work (translator + request/response builder).

Currently, I'm able to do :

• ✔️ register / update/ deregister
• ✔️ also send Read / Write / Execute / Create request.

What is not implemented :

• ❌ observe I didn't look at java-coap api about that for now. (this will probably the painful part .... observe is always the painful part...)
• ❌ send is not implemented (this should be not so hard to implement)
• ❌ All composite Operations because java-coap doesn't support Fetch and IPatch.

There is also some TODO which I need investigate, this will probably lead to some discussion with java-coap maintainer.

Next step ?

• maybe adding a way to have several endpoints provider this ways I could have java-coap and californium at the same time.
• probably trying to redesign tests to be able to execute it with different endpoint providers. (this way not need to rewrite all tests)

[JaroslawLegierski]

In my last version client I implemented initial version of Read function. I took the ResponseCodeUtil class from you 😄. Some variables are still hardcoded but I will try clean it in new versions e.g. ServerIdentity (needed by ReadResponse in ObjectResource). In cf ServerIdentity was available in CoapExchange I don't know if there is something similar in java-coap api.

[sbernard31]

In my last version client I implemented initial version of Read function.

👍 I will look at this next week.

In cf ServerIdentity was available in CoapExchange I don't know if there is something similar in java-coap api.

Yep this is something we will need to ask especially for coap over dtls

As for now we just test with coap, I create identity like this : return Identity.unsecure(coapRequest.getPeerAddress()); See in LwM2mCoapResource.getForeignPeerIdentity(CoapRequest coapRequest) (in my branch)

[sbernard31]

I moved a bit forward.
This is still available in java-coap branch.

I added support of :

• ✔️ send operation was not so hard. (commit 21134c6)
• ✔️ observe was a bit complicated and we do not persist observe relation (See General discussion / feedback from Leshan Team open-coap/java-coap#27 (comment) for more details). (commit 4c1913b, 475baf7)

(Note this is still a draft, that means a lot of polish/tests are missing)

[szysas]

Could you make it a draft PR? It would be easier to write comments or ask questions.

[sbernard31]

Could you make it a draft PR? It would be easier to write comments or ask questions.

Yep, this is done #1382.

[JaroslawLegierski]

From my side, only small progress in 3d49df0 - mainly I found and corrected some bugs in the read function and added send. I also used Your random token generator.

[sbernard31]

I finally finished to modify our integration tests to be able to test different transport (See #1425)

These changes should allow us to run most of our integrations tests with java-coap.
I will be move forward on this now.

[sbernard31]

I have a Leshan server which passes all integration tests using java-coap (with some limitations see #1382 (comment))

I think before to go deeper at server side, it would be better to move forward at client side.
This way if we have a client and a server based on java-coap we could try to use it with coap+tcp.
(I guess the bootstrap server should not be so hard to do so we can let it aside for now)

@JaroslawLegierski did you move forward on the client ? Do you plan to do it OR should I reuse your work and start to work on it ?

[JaroslawLegierski]

Unfortunately I didnt you move forward on the client from last time 😟. Because currently most important for us is #1421 topic please feel free to reuse my java-coap work

[sbernard31]

Unfortunately I didnt you move forward on the client from last time.

@JaroslawLegierski no problem. 🙂

please feel free to reuse my java-coap work

Thx 🙏

Because currently most important for us is #1421 topic

Let's talk about #1421 in the corresponding issue.

[sbernard31]

I move a bit forward about Client side support : #1443

[sbernard31]

There is now first implementation of CoAP protocol based on java-coap(fork) in master :

• Add an EndpointProvider at Server side for CoAP based on java-coap(fork) #1382 (comment)
• Add an EndpointProvider at Client side for CoAP based on java-coap(fork) #1443 (comment)

The main purpose was to test transport layer abstraction and I think this is done now, so I will close this issue.

But there is probably more work to do to make it fully production ready.