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