Re: [cf-dev] Request/Response matching for DTLS-Secured exchange

["Kovatsch Matthias" <kovatsch@xxxxxxxxxxx>]

Okay, I think we are getting closer :)

 

1) Message Context.

In this solution, I would not return detailed fields too ... That's why I said "as Kai explains : MessageContext.equals() is used for matching". So we are agree on this point.

Ah, they were only listed to get an idea of the members. Yet it also looked like a single class to me. I would go for:

interface MessageContext
class UDPMessageContext (with remote socket address, nothing else)
class DtlsStrictMessageContext (which uses epoch next to the other stuff)
class DtlsFlexibleMessageContext (which uses ciphersuite etc.) – let’s look for a better name ;)

Did you mean you don't see the semantic dependency ? If you forget the CoAP use case how did you choose what you put in the MessageContext ? or what is compared in MessageContext.equals() ?(This is the same thing for me)

The instance of the MessageContext is produced by the connector that knows the specific fields. In the unlikely case someone uses element-connector alone, the application gets it from UDPConnector. When an application uses Scandium, it configures the mode and then gets the instance from DtlsConnector.

 

The context is nothing random in CoAP. A UDP socket address is a classic message context. So is DTLS session epoch. If an application needs something exotic like our flexible DTLS mode, we can consider adding it, if it makes sense.

I think we are agree on the way we could implement this solution ... what I tried to show you is the semantic dependency issue.
(which is not a big one if we consider that element-connector and scandium aim only/mainly CoAP protocol.)

Sorry, I still don’t see the dependency issue :)
Did I miss something? Or does my explanation above make sense?

2) DTLS Security Context.

In this solution, there is specific fields. That the way to move the choice of what it is needed for CoAP request/response matching in the CoAP code. (Californium.core), and so move the semantic dependency from (scandium, element connector => CoAP spec)  to  (californium.core => DTLS spec).
I think this is not so weird as the CoAP spec refer to the DTLS spec.

We should only consider this if we cannot do it without dependencies in 1)---unless... There might be something to solution 2) for the future issues like the handshake problem and more importantly, we will need a small redesign of the Endpoints for alternative transports anyway.
It could also work in such a way that we encapsulate this in specific Endpoints: CoapEndpoint for UDP, CoapsEndpoint for DTLS, CoapTCPEndpoint for TCP, etc. -- the latter is something we need for the alternative transports anyway. Scandium might offer a CoapsEndpoint, since it is part of the Californium project and people who want DTLS only can simply ignore it (but have an example on how to use the rest).

 

That reminds me: I still want to rename CoAPEndpoint to „CoapEndpoint“ to be consistent. Hope that does not introduce too many breaks for Leshan…

 

Ciao
Matthias