Websocket session id sharing
Tim Fox
Hi,
I am trying to understand the motivation behind:
# For WebSockets, as opposed to other transports, it is valid to
# reuse `session_id`. The lifetime of SockJS WebSocket session is
# defined by a lifetime of underlying WebSocket connection. It is
# correct to have two separate sessions sharing the same
# `session_id` at the same time.
Up til now, I've been assuming that sessions are cross transport, e.g.
I could have an xhr polling connection receiving messages that were
sent by a jsonp send on the same session id.
However, (at least) for websockets this does not appear to be the
case.
Is it indeed the intention that sessions are supposed to be shared
across transports? In real life wouldn't all sends and receives for a
particular session be using the same transport?
The second question, is, if sessions are indeed supposed to be cross
transport, why not allow websockets to be too?
Tim Fox
On 09/12/11 13:57, Tim Fox wrote:
On 09/12/11 13:53, Sergey Koval wrote:Hi,
Per sockjs-protocol, session id is internal to the sockjs and should never be exposed to either client or server application.Because websockets protocol is duplex, there's no need to have session for it at all. If websocket connection was established and then dropped, it will be considered as proper disconnect and sockjs won't fallback to polling transport. There's no way client will use websocket to receive data and use XHR to post data to the session.
Why not?
And if this is true for websockets, why isn't it true for other transports? Why not just make session id never shared between transports?
Serge.
Marek Majkowski
You hit the nail in the head, again.
For websockets re-using the session doesn't make much sense. So,
for ws feel fre to just ignore "/server_id/session_id/" prefix at all.
For other transports... well... switching protocols from the sockjs-client
is _not_ supported. (actually, there might be a nasty race when I now
think about it, whoops.)
But sockjs-node is implemented in a way that supports switching
protocols. IE: you may do "xhr_send" on any non-ws transport, as well
as you may do "jsonp_send". You may get data using "eventsource",
and pull next bunch using "xhr_streaming".
I think structuring a code that allows that is a good practice, but
this is generally not used by sockjs-client, so I think we shall
call it "implementation dependent".
Marek
Marek Majkowski
> On 09/12/11 13:53, Sergey Koval wrote:
> Per sockjs-protocol, session id is internal to the sockjs and should never
> be exposed to either client or server application.
Yes. Sockjs-client might theoretically have a feature to switch transports
in flight, right? (it doesn't)
> Because websockets protocol is duplex, there's no need to have session for
> it at all.
Yes. Also, there kind of always is a receiving connection hooked into ws
transport, so anyone trying to pull data from the same session_id should
get 'close frame, c[2010,"Another connection still open"]'.
Websockets are quite special, unfortunately.
> If websocket connection was established and then dropped, it will
> be considered as proper disconnect and sockjs won't fallback to polling
> transport. There's no way client will use websocket to receive data and use
> XHR to post data to the session.
>
>
> Why not?
>
> And if this is true for websockets, why isn't it true for other transports?
> Why not just make session id never shared between transports?
Because 'close' event on websockets has different semantics than
on polling/streaming transports.
When server receives an http-based request, when the request goes
away (is closed), it doesn't mean anything semantically for SockJS.
It's just a polling request that went away.
In other words: many-http-requests -to- single-sockjs-session
But it's different for ws: single-ws-request -for- single-sockjs-session.
This is due to a fact, that when ws go away, that clearly means
the browser went away or the client closed a session.
There is no third option. So when we receive 'close' on ws, we
know enough, and we should close the session.
Marek