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

[Simon Bernard <contact@xxxxxxxxxxxxxxx>]

I suppose we could add Security Contex at message level in a same way we add the principle but this is done only at request reception and we need it when we send a message too. (to fill the exchangeBy* maps).
Maybe we could had a getSecurityContext(InetSocketAddress) on Connector, we can call it to fill the exchangeBy* maps before we send a message ? But this solution seems to have a "transactional" issue. (I mean If an handshake is done between the "getSecurityContext" and the "Connector.send" :(

Yes. Also this implies security for the normal CoapEndpoint, and hence also a dependency on Scandium, even when it is not used.

[Hudalla Kai (INST/ESY)] Using the approach above, this can easily prevented by means of having UdpConnector return an instance based on the peer’s address and Scandium return an instance based on peer’s address and session ID. Both MessageContext implementations would then need to override hash() and equals() accordingly so that Californium can simply use sentCtx.equals(receivedCtx) to do the check …

[Simon] I thought about that too, but after reflexion I'm not sure this kind of abstraction was really relevant, I mean the choice of what we will set in the MessageContext will be done in function of our needs in CoAP request/response matching.
This looks a bit strange ? I mean for example, if we are in flexible mode we don't want the epoch field, but if I don't use CoAP why should I can have access to epoch field ?

[Matthias] (Just in case: Indeed I meant to do the strategy pattern thing instead of this J) It would actually be the hashmaps in the Matcher that do this comparison when trying to retrieve an existing Exchange based on the key. Since we still need MID, Token, and URI keys, the corresponding key classes would be fed this MessageContext.

Probably, the key classes should be moved from Exchange to the Matcher.

Also note that KeyToken currently relies on the Token alone, enabling such endpoint address changes for Observe!

Simon, do you actually plan to this for the Release or is it more a long-term thing? Because we also need to consider other transports for this context…

[Simon] If the release date is the 16th september I think this is clearly too short, but we would like to have usable version as soon as possible. (a milestone version next the release will be ok for us)

Ciao
Matthias