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
Daniel Svensson
<image001.png>
Elvaco AB, Teknikgatan 18, 434 37 Kungsbacka
Tel: +46 300 30250
Internet: www.elvaco.se
C O N F I D E N T I A L I T Y
The contents of this e-mail are confidential to the ordinary user
of the e-mail address to which it was addressed, and may also
be privileged. If you have received this e-mail in error, please
e-mail the sender by replying to this message. Elvaco
reserve the right to monitor all e-mail communications from
external sources for the purposes of ensuring correct and
appropriate use of property and trademarks owned by Elvaco.
Elvaco AB, Gothenburg ©2010.
Hi Kai
Thanks for confirming. I will look in to it, and hopefully make a pull request.
/Daniel
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
Regards,
Kai
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
Thanks for the tip Kai.
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 …
You should implement your own org.eclipse.leshan.server.client.ClientRegistry, then pass it at creation :
LeshanServer server = new LeshanBuilder().setClientRegistry(new YourClientRegistry()). .... .... .build()
Le 14/01/2016 18:29, Gajjala Vinay a écrit :
Hi
Whenever my server is restarted it is losing the client state like registration etc., there by any update registrations after server restart from the clients are failing.
I like to know is there a way I can implement/extend the current Client cache which Leshan stores in memory to persist and share across cluster?
Thanks
Vinay
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.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev
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.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
