| Re: [leshan-dev] Persistence & Clustering of Client |
|
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. |
