| Re: [leshan-dev] Persistence & Clustering of Client |
|
Hi Kai Thanks for the detailed answer, it was very helpful.
I will take a quick look at the
SessionListener interface. But I’m starting to think that it would be better for our use to let the client re-register, and then restart any observations that
it had before the connection was lost. Daniel Från: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
För Hudalla Kai (INST/ESY1) Hi Daniel, this is not a bug but part of the normal operation of Scandium
J The Connection object’s main purpose is to separate the negotiation of
pending connection state (“ongoingHandshake”) from maintaining the current connection state (“establishedSession”). The connection state contains things like the negotiated crypto params (in particular key material) but also counters for keeping track of inbound
and outbound DTLS records. So when a client starts a new connection to a server, the server creates a new Connection instance and ServerHandshaker instance which is used to
do the handshake with the client. Once the handshake is complete, the negotiated connection state (contained in a DTLSSession object) is transferred from the “ongoingHandshake” to the “establishedSession”. From then on each record exchanged between client and server will induce a change in the corresponding inbound and outbound counters in the DTLSSession
objects. You might be tempted to conclude from this that every change to the DTLSSession should result in an update in the DB but I would argue that that is probably not such a good idea because these updates simply happen too frequently (once for every record
received/sent) and will probably kill throughput. We haven’t spent too much time on this whole issue so far but my personal take would be that it should be sufficient to persist the connection state
to the DB only when the DTLS epoch changes, i.e. when the pending connection state becomes the current connection state (when a handshake completes). The important values to persist are the crypto params (which do not change during the whole lifespan of an
epoch) because only these are required for resuming a connection. This way one could support fail-over between Scandium instances by means of clients having to resume their connection once they realize that the server they have been talking to has died (note
though that this can currently only be detected at the application layer by means of missing response messages). Following this approach we will first need to make ConnectionStore support the SessionListener interface inorder to receive callbacks when a handshake
completes (so that the current connection state can be persisted). Does this make sense to you? Kai From:
leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
On Behalf Of Daniel Svensson Hi Kai There seems to be a bug in Californium. When I implemented a ConnectionStore that stores the connections in db, my client started to fail on registration. I conducted a test to see where the problem lies. It seems that the connection is being changed after it’s stored in the ConnectionStore. These snippets below where used to test this suspicion.
Test 1: I wanted to rule out as mutch logic as possible, and only test if my conversion of the connection is working (I need to convert as Connection isn’t
serializable). //This would be replaced by DB logic, but currently holds the session (test is performed with 1 client).
private DTLSConnection storedConnection = null; @Override public boolean put(Connection connection) { //Convert to an object that may be saved to db storedConnection = ConvertConnectionToDTLSConnection(connection); //DB logic goes here
return true; } @Override public Connection get(InetSocketAddress inetSocketAddress) { //DB logic goes here if(storedConnection != null) { //Convert to a Callifornium DTLS connection. return ConvertDTLSConnectionToConnection(storedConnection); } else { return null; } } Result on the server side is: INFO: Could not create X.509 certificate from byte array: Could not parse certificate: java.io.IOException: Empty input jan 20, 2016 11:52:20 FM org.eclipse.californium.scandium.dtls.HandshakeMessage fromByteArray SEVERE: Received unexpected ServerKeyExchange message in NULL key exchange mode. -------------------------------------------------------------------- Test 2: I wanted to rule out the possibility that there is a fault in my conversion, and verify my suspicion. //This would be replaced by DB logic, but currently holds the session (test is performed with 1 client).
private Connection storedConnection = null; @Override public boolean put(Connection connection) { //Keep the reference intact. Changes made to connection will be reflected on storedConnection. storedConnection = connection;
return true; } @Override public Connection get(InetSocketAddress inetSocketAddress) { if(storedConnection != null) { //Convert to my connection type. DTLSConnection a = ConvertConnectionToDTLSConnection(storedConnection); //Convert back to Californiums connection type. return ConvertDTLSConnectionToConnection(a); } else { return null; } } Result:
The client registers successfully! Kind Regards/Vänliga hälsningar
E-mail:
Daniel.Svensson@xxxxxxxxx Internet:
www.elvaco.se
C O N F I D E N T I A L I T Y
Från:
leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
För Daniel Svensson Hi Kai Thanks for confirming. I will look in to it, and hopefully make a pull request. /Daniel Från:
leshan-dev-bounces@xxxxxxxxxxx
[mailto:leshan-dev-bounces@xxxxxxxxxxx]
För Hudalla Kai (INST/ESY) Hi Daniel, I am afraid that this is (currently) the way to go, i.e. if you want to pass in a DTLSConnector instance using your own ConnectionStore implementation
then you will need to either implement LwM2mServer or subclass LeshanServer. However, what I would like even better was a pull request for making it possible to use a custom DTLSConnector instance in the LeshanServer(Builder) class(es)
J
Kai From:
leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
On Behalf Of Daniel Svensson Hi I’m currently working on the same problem. What is the best practice for persisting session state at DTLS level? I found out that DTLSConnector takes a ConnectionStore as an in parameter (link below). Do I need to implement my own LwM2mServer, in order to pass
an ConnectionStore to the coapserver or is there a better way? Kind regards Daniel Från:
leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
För Gajjala Vinay Thanks for the tip Kai. From:
leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
On Behalf Of Hudalla Kai (INST/ESY) Vinay, please also be aware of the state potentially managed at the Calfornium level, in particular if you use DTLS. Californium (or to be more precise
its Scandium component) keep track of DTLS session state for each client in memory as well. Thus, if your server contains the full stack (leshan, Californium, Scandium) you will also need to take care of persisting session state at the DTLS level and probably
also make your clients try to “resume” their DTLS session if they are not able to connect to the server after the server has restarted …
Regards, Kai From:
leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx]
On Behalf Of Simon Bernard You should implement your own org.eclipse.leshan.server.client.ClientRegistry, then pass it at creation : Le 14/01/2016 18:29, Gajjala Vinay a écrit :
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure,
either whole or partial, is prohibited. |
