Session freeze & resume

[oberstet]

WAMP session freeze & resume suport both in client library and router that allows for:

• maintain WAMP sessions across loss of transport connections
• freeze WAMP session and resume upon new transport connection
• transport connection can even have different flavor
• resuming a session uses a shared secret established over a Diffie-Hellman exchange
• because resuming is secure, any authentication is preserved

Allows session to live in the presence of intermittend network loss, e.g. on mobile networks.

Allows session level handover, e.g. while moving from one Wifi network to a neighboring Wifi network, or even to a different transport like a HSPA connection.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[oberstet]

A session frozen on the server-side would buffer up events that would have been received by the session had it been still active. The buffering will have a configurable limit - both in how long the session is still maintained in a frozen state on the router, as well as how many messages are buffered at max.

Actually the buffering could be at the transport level, as this allows easy resume: just send out buffered WAMP messages held in an out queue.

When a WAMP transport is lost, instead of closing the WAMP session (the instance of ApplicationSession or the user class derived thereof), replace the WAMP transport with a RetainerTransport, which simply buffers up any messages being sent.

Later, when the real transport resumes, the messages from the RetainerTransport are read and actually send over the real transport. After all previously buffer messages have been sent, new messages get sent.

A ResumableTransport is the counter-part of the RetainerTransport. The ResumableTransport will note the number of WAMP messages received on the WAMP session. If the underlying real transport reconnects, the ResumableTransport will ask it's counter-part RetainerTransport to resend beginning from the last know good and processed incoming WAMP message.

A full-duplex WAMP transport consists of a pair, with a RetainerTransport for the outbound connection, and a ResumableTransport for the inbound connection.

The transport also has an underlying "real" transport. However, the real transport can disappear, can be reconnected, can even be connected using a different networking technology under the hood.

[oberstet]

Above approach of buffering at the WAMP transport level is transparent at the WAMP application level. Ideally, only the send/receive timings of the WAMP messages, but not their order nor their content change under a Resumable-Retaining WAMP transport.

However, I'm not sure if that is necessary, or desirable.

Because, let's take events. Subscribers might not want to loose events. On some topics, or on all topics. They might want to get historic events when they freshly boot. In that case, there wasn't any WAMP session to resume. Publishers indeed might want to have their outbound events being buffered up until an underlying transport resumes.

Then RPC. When a callee disappears, the value of buffering up calls that would be served by the lost callee seems dubious. One could argue that the calls really should fail. And the caller role. When there is no transport, what whould outgoing calls do? Buffer up .. really?

[hawkowl]

Related: #892 and wamp-proto/wamp-proto#260

[oberstet]

as discussed extensively on WAMP protocol (eg wamp-proto/wamp-proto#264) : won't fix (for now) .. "too invasive / doesn't really fit wamp design / unclear how to do it"