non-blocking session provider

[WyriHaximus]

Currently the session provider reads out session data in a blocking way. This is okey but not an option if we want to go for a full non-blocking websocket server. Creating an deferrable interface would allow for predis async to be used as well as still supporting sf2 sessions within a wrapper. It would make the plain sf2 sessions a bit more complicated but allows more adapters then just predis. Below is some pseudo code how it could be done.

interface {
    readSession(sessionId);
}

concrete class {
    readSession(sessionId) {
        promise = new promise;
        this->client->get(sessionId, promise);
        return promise;
    }
}

Another thing is should the onOpen call wait for the session to be retrieved or fire anyway and fire another call for the session data?

Possible adapters:

• PredisAsync
• MySQL
• Blocking adapter running in a seperrate process made possible by:
  • 0MQ
  • ChildProcess

[cboden]

#142

[cboden]

ping @nervo

[PaulRotmann]

Hey! Thanks for reporting this issue 🙏

We're giving Ratchet some much-needed love and attention! As part of our issue cleanup initiative (#1100), we're reviewing and closing long-standing feature requests that may no longer be relevant to current development priorities.

This session enhancement request from 2013 is interesting, but the landscape has changed significantly since then. With improvements like keep-alive support and other modern approaches, this specific implementation would likely be handled differently today if we were to pursue it.

Given the potential architectural changes we're considering for future versions, we're closing this issue for now. If this functionality is still important to you, we'd love to continue the conversation in our GitHub Discussions where we can explore modern approaches to session handling. Just reference this issue when you post.

If you want to support Ratchet, please consider sponsoring our work! ❤️