[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [leshan-dev] Persist sessions to restore connections
|
Thx a lot Achim for this feedback. Some remarks inline
Le 02/10/2018 à 09:48, Kraus Achim (INST/ECS4) a écrit :
Hi all,
just to add my 2 cents:
The DTLS server/client role exchange can only work, if your client is reached by the same ip-address.
I’m not sure, how often this is successful.
For none queue mode, this should be the case ? device IP address/port
should be fixed/static. But I don't know if TLS library easily support
this kind of role exchange... I think scandium support it but this is
maybe not so common.. If you have any idea about how failover should be
handled in LWM2M, please comment :
https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/410
Scandium (2.0.0-M12) offers two variants of the session cache:
- SessionCache for a DTLS server. If a resuming client_hello is received, then the cache is used to look up the session from the cache.
- ClientSessionCache for a DTLS client. If scandium is started, connections marked for resumption are created based on that cache. If data is send to such a peer, the DTLS client tries to resume such sessions.
With a "role-exchanging server", the server may also use a ClientSessionCache.
But anyway, as Simon wrote, resumption will only short the handshake, it will not solve the current request/response matching definition. To overcome that, the none-RFC7252 compliant RELAXED matching may be used.
Thx for the detailed explanation. (I need to change the wiki page about
that)
The persistent observations are broken in californium 2.0.0-M12!
Unfortunately I got aware of that too late for the M12.
A PR https://github.com/eclipse/californium/pull/761 is pending, which will fix it.
We would continue the discussion about that at :
https://github.com/eclipse/californium/issues/668
Mit freundlichen Grüßen / Best regards
Achim Kraus
(INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | http://www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
From: leshan-dev-bounces@xxxxxxxxxxx <leshan-dev-bounces@xxxxxxxxxxx> On Behalf Of Simon Bernard
Sent: Montag, 1. Oktober 2018 18:30
To: leshan developer discussions <leshan-dev@xxxxxxxxxxx>; Arjun Kamath <junnaonly@xxxxxxxxx>
Subject: Re: [leshan-dev] Persist sessions to restore connections
Hi,
I just write a new wiki page to explain this : https://github.com/eclipse/leshan/wiki/Server-Failover
(This means the page is maybe not so clear and full of spelling mistakes ^^)
But I hope this would be clearer for you.
Simon
Le 01/10/2018 à 11:00, Arjun Kamath a écrit :
Hi all,
I've been looking for a way to ensure that notifications sent by a client are continued to be received by the LWM2M server after the server restarts/crashes and reboots.
I first unsuccessfully tried to persist connections, but that seemed unnecessarily complex.
After the recommendation from this issue: https://github.com/eclipse/leshan/issues/554, I tried to persist DTLSSessions using the sessionCache interface. For this I had to implement/adapt serializers for some classes.
Luckily this works! When a client registers, the DTLSSession is persisted on sessionEstablished event. Then the server observes a resource and notifications are received. The server then stops and restarts. On restart the sessions are read and for each session a connection object is created and the inMemoryConnectionStore is populated.
The notifications thus continue to be received.
All good, but I'm trying to understand why exactly this works and when would it not work. Since the session was saved when the client registered, there can be a significant time between saving a session and restoring it.
My first guess is that since we're talking about UDP here, the server simply assumes that some packets were lost and just continues as though nothing happened. But this explanation seems to simple.
Also, it appears that losing parts of the connection object (basically everything other than the session object) has no bearing whatsoever to the normal functioning of the server.
Regards,
_______________________________________________
leshan-dev mailing list
mailto: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
_______________________________________________
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
