Just to be clear in my previous email, I propose 2 different
solutions for context abstraction with pros and cons, I 'm not sure
that was understood.
(Maybe my english does not help :/ )
Some more thoughts from my side:
1) Message Context.
A first solution could be to create MessageContext at
element-connector level which will contain :
- peer address for UDP.
- peer address + session ID + epoch for DTLS strict mode.
- session ID + cipher Suite for DTLS flexible mode.
This context would be used to build Keys in
Matcher. (as Kai explains MessageContext.equals() is used
for matching)
I would not return detailed fields like epoch
for the context, but an instance that can serve as key
directly. For this, it must implement equals() to be used as
a key in a hashmap, which does the actual matching.
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.
This is clearly elegant and make the Californium CoAP stack
totally independant of security layer.
But the real meaning of MessageContext is "Elements
needed by CoAP to do Request/Response Matching", in other word
we introduce a semantic dependency in Element-connector and
Scandium to CoAP.
This is acceptable if element-connector and scandium aim
only/mainly CoAP protocol.
I don’t see it. Most protocols match per
endpoint, which is either socket address or the strict mode
key. If there pop up any other special cases for other
reasonable protocols (like the DTLS flexible mode), we can
add it.
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)
An example which shows this dependency is a bit weird is
that the choice between strict or flexible mode, which is a
CoAP choice, will be done in Scandium (When we will create
the MessageContext object)
This could also be error prone is someone adds a field in
MessageContext without knowing this will impact the
Request/Response Matching of CoAP.
At the application layer (usually CoAP), the
developer decides whether to include only element-connector
or also Scandium and also the mode. The application layer
only gets an instance (from the connector probably) of
something that implements MessageContext and uses it as key
for the hashmap. It does not require specific fields. When
Scandium is used, the secure MessageContext class from Sc
will now how to compare itself to other contexts. The mode
could go into the network config for Scandium.
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.)
2) DTLS
Security Context.
We could add the Security Context at Element-connector level
which is just a map of properties (String->Object) and
maybe a protocol name (String)
As I said, there shouldn’t be access to
specific fields. This should solve this.
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.
The main headache is how to put a message into
the hashmap on send. For UDP, the remote address is known
and could be passed to the connector to get the
MessageContext instance. For DTLS, as mentioned, the
DtlsConnector would need to perform a handshake to return a
MessageContext. Maybe this is a good way? (BTW: I think we
need to adjust the ReliabiltyLayer timeouts for DTLS
messages.) Do we want to support multiple security contexts
in parallel?
This is the next problem to solve as we will agree on the context
abstraction.
|
