Add a Redis Session Store to share session

[sbernard31]

The idea is to create a RedisSessionStore to share session between several node when leshan is used in a cluster.

This issue was triggered by @Przem83 #1049 (comment)

We are working on a usable version of a Leshan server that would use a shared session store based on Redis instead of the in-memory one. So if you would be interested in making this part of the Leshan demo server in release 2.0.0 we can provide you with the code when we're finished (currently we're still sorting out some serialization issues and doing some tests). I know that you have already done some test in this regard in the past so it might also be interesting to compare our results.

Not sure we will integrate it but this issue can be used to talk about this.

[sbernard31]

@Przem83 internally we are using a SessionStore (previously called SessionCache) based on Redis.

Our implementation is limited to PSK (probably one of the reason if is not already provided in Leshan release)

I adapted the code to new Californium API but I didn't test it.
I put the code in a session_store Leshan branch, this way you can have a look at this : 627136a

Maybe it could help you.

[JaroslawLegierski]

Regarding to issue triggered by @Przem83 we developed PoC of Shared DTLS Session Store based on redission client. Our solution you can find here: (https://github.com/Przem83/leshan) branch opl/session_store/redisson (https://github.com/Przem83/leshan/tree/opl/session_store%2Fredisson))
Because of usage redission client library following 8 Californium classes needs to be modified (only implements Serializable interface must be added to them):

• org.eclipse.californium.scandium.dtls.DTLSSession
• org.eclipse.californium.elements.auth.RawPublicKeyIdentity
• org.eclipse.californium.elements.auth.AdditionalInfo
• org.eclipse.californium.scandium.dtls.SessionId
• org.eclipse.californium.scandium.dtls.SignatureAndHashAlgorithm
• org.eclipse.californium.elements.auth.PreSharedKeyIdentity
• org.eclipse.californium.elements.util.Bytes
• org.eclipse.californium.elements.auth.X509CertPath

@sbernard31 What is your opinion about this solution ?

[sbernard31]

I try to look at this next week :)

[sbernard31]

Some context about my thinking about the leshan-server-redis component :

First point, I must confess that I often think about this module and I ask myself if it should really be part of the Leshan scope. I mean the lib must provide a way to let user implement persistent/shared store but I'm not sure we need to provide one implementation in the library itself.

I guess there pros :

• users seem to use it
• this help to ensure our API really allow to implement persistent/shared store

and cons :

• this is need to be maintained
• handling backward compatibility of persisted data can be painful.
• time taking on this can not be used to implement core LWM2M library.

Second point, currently leshan-server-redis depends on californium/scandium but with #1025, I guess we need to go to something with does not depends of transport layer. So I'm not so sure now that a RedisSessionStore should be placed in leshan-server-redis. 🤔

If we want to talk more about this point I can create a dedicated issue, just let me know.

---

About the RedissonSessionStore,

I don't know so much about redisson, so not sure to get the benefits comparing to jedis. But if we decide to put in in Leshan I guess we should avoid to have 2 Redis client library. Anyway, if this is not integrated in Leshan there is no problem about using Redisson. At first sight the code seems very simple. Maybe it makes more sense to pass a RedissonClient to the constructor ? (again if this is for internal usage, this seems ok like this too)

About "Magic serialization/deserializaion", this allow to write less code but this can be annoying to handle changes about data format / backward compatibility. (This can also create silent break) Anyway for a kind of cache this is maybe not an issue, if you know this is OK to sweep all old data when data format changes.
Note: Scandium already provide a way to serialize/deserialize DtlsSession. (see 627136a)

About Making Californium class serializable, please ask directly to Californium Maintainer. (I'm out of Cf now)

Last point, when we try to implement this we face a situation where most of our clients create a lot of new Session. As only the last one is generally reused we try to remove the oldest one. (see RedisSessionStore.put(), We implement it only for PSK. but maybe this is not an issue for you (or you don't face it ?)

[JaroslawLegierski]

We think that using Redis server as leshan data repository is very valuable for leshan users. Therefore, starting a discussion is a very good idea.

[JaroslawLegierski]

After internal disscusion we decided to develop a RedisSessionStore based on shared by you (627136a) code
In the first step, we would like to add session cleaning based on RawPublicKeyIdentity and X509 (in a similar way as it is already done for PSK).

[madhushreegc]

Do we have this feature integrated? This is very helpful .

[sbernard31]

In #1096 (comment) I said :

currently leshan-server-redis depends on californium/scandium but with #1025, I guess we need to go to something with does not depends of transport layer. So I'm not so sure now that a RedisSessionStore should be placed in leshan-server-redis.

More than 1 year later, this finally happens. With new transport layer abstraction design, leshan-server-redis has no more dependency to Californium/Scandium.
So currently, there is no more module in Leshan where we could put this RedisSessionStore.

We could consider to create a new module but currently I really feel this is out of Leshan scope.
If you look at 627136a, there is no dependency to Leshan or to any LWM2M concept. This is pure DTLS / scandium stuff.

So I guess this would maybe make more sense to :

• put it in Californium,
• or create a new dedicated project (maybe a simple github one not specially hosted by eclipse foundation) and release it in maven central,
• As releasing on maven is maybe a bit overkill just for this, maybe just creating a wiki page with a link to this repo containing the last version of this class.

@JaroslawLegierski do you have a more recent version of RedisSessionStore to share ?

[JaroslawLegierski]

We tested session store feature using this branch. But from what I can see the RedisSessionStore version is probably the same

[madhushreegc]

I will create a simple project with new transport layer abstraction and try this feature.

[sbernard31]

I will create a simple project with new transport layer abstraction and try this feature.

Good to know 👍
Let us know if you find anything smelly with transport layer abstraction (design / api / anything) 🙏
Maybe you could also try to implement NIDD transport with new design : #1046 ?

[madhushreegc]

Sure . Thank you .

NIDD is over Http , here i want to use DTLS so probably I cannot try the NIDD .