Clarification of when sessions can be closed

[Tim Fox]

I'm trying to get vert.x to work with 0.2.1 and bumping into a few issues along the way.

Basically I'm still trying to figure out at what point a server side session can be discarded and thrown away. I had this same issue implementing 0.1 and unfortunately it hasn't gone away.

In the absence of any canonical documentation in SockJS protocol which describes the life cycle for each transport, I am trying to piece together a picture by looking at what the protocol tests expect. So far the picture I have assembled is a little odd. This process seems analogous to having to discover an elephant in a dark room using only a stick to poke it with. It would be much easier to just be able to turn the light on and say "aha! it's an elephant". ;)

Looking at the HandlingClose test it seems that, for xhr streaming (at least). If a user attempts to post a listener to the same session where a listener already exists, it should receive the message "Another connection still open", but the session should not yet be closed.

If another post of a listener is attempted, then "Connection interrupted" should be returned. At this point the session *can* be closed.

So it's not the first attempt to add a listener where one already exists that should trigger session close, it's the second attempt?

[Marek Majkowski]

SockJS assumes that there may be at most one listener on a
session. Any other listener will receive ""Another connection still open"
close message. Tested for example here:

http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.2.1.html#section-47

The session internally does not change it's state. If it was opened it
remains opened.

A separate thing is that in SockJS 0.2 we decided that an interrupted
listener should be treated as a fatal error. Basically, when a HTTP
polling/streaming
request is being interrupted by the browser (or network) it is
possible that some messages in transit may have been lost.

SockJS-server is obliged to abort session in such case, and set a close
reason to "Connection interrupted". This is tested here:

http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.2.1.html#section-137

What we do in this test:
- open streaming connection (ie: add listener)
- add another listener, verify we received the "Another connection
still open" message.
(all is good at this point)
- abruptly break the fist listener (see " r1.close() " line)
- add another listener, verify that in fact we can't receive messages,
as the server closed the connection.
- In such case the server is allowed to behave in two different
flavours:
1) it may just forget about the session and answer with open frame
(ie: start a new session). The sockjs-client will detect that
and complain.
2) set a close reason to "Connection interrupted" on the session
and give us a close frame with this reason.
- see the line:
self.assertTrue(r3.read() in ['o\n', 'c[1002,"Connection
interrupted"]\n'])

Hope that makes it clearer.

Marek

[Tim Fox]

Ok

>
> A separate thing is that in SockJS 0.2 we decided that an interrupted
> listener should be treated as a fatal error. Basically, when a HTTP
> polling/streaming
> request is being interrupted by the browser (or network) it is
> possible that some messages in transit may have been lost.
>
> SockJS-server is obliged to abort session in such case, and set a close
> reason to "Connection interrupted". This is tested here:
>
> http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.2.1.html#section-137

By "abort" do you mean "remove all traces of the session from the server"?

>
> What we do in this test:
> - open streaming connection (ie: add listener)
> - add another listener, verify we received the "Another connection
> still open" message.
> (all is good at this point)
> - abruptly break the fist listener (see " r1.close() " line)
> - add another listener, verify that in fact we can't receive messages,
> as the server closed the connection.
> - In such case the server is allowed to behave in two different
> flavours:
> 1) it may just forget about the session and answer with open frame
> (ie: start a new session). The sockjs-client will detect that
> and complain.
> 2) set a close reason to "Connection interrupted" on the session
> and give us a close frame with this reason.

If the session has been destroyed then I don't see how you return
"Connection Interrupted" since that would require some session state on
the server to remain so you know the session has been "interrupted".

Unless of course, aborting doesn't mean destroying the session?

Another thing I don't understand is when a session is closed by the
server due to it being closed by the application explictly or session
timeout.

This seems to be tested by test_close_frame:

# When server is closing session, it should unlink current
# request. That means, if a new request appears, it should receive
# an application close message rather than "Another connection
# still open" message.

But again, if I've closed the session, how can I return such a message
since I will require state to remain so I can return "go away"?

[Marek Majkowski]

>> A separate thing is that in SockJS 0.2 we decided that an interrupted
>> listener should be treated as a fatal error. Basically, when a HTTP
>> polling/streaming
>> request is being interrupted by the browser (or network) it is
>> possible that some messages in transit may have been lost.
>>
>> SockJS-server is obliged to abort session in such case, and set a close
>> reason to "Connection interrupted". This is tested here:
>>
>>
>>  http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.2.1.html#section-137
>
>
> By "abort" do you mean "remove all traces of the session from the server"?

Usually sockjs-server must keep some session state (which contains
the close reason) for some time after the session is marked as closed.
See:

http://sockjs.github.com/sockjs-protocol/sockjs-protocol-0.2.1.html#section-49

But, in this particular case ("Connection interrupted") the server is allowed
to just remove the session alltogether when the listener
is abruptly broken. This case is an exception and this behaviour
is not allowed in any other circumstances. Normally the server
must keep the close reason around for some time (5 seconds if I remember).

>> What we do in this test:
>>  - open streaming connection (ie: add listener)
>>  - add another listener, verify we received the "Another connection
>> still open" message.
>>    (all is good at this point)
>>  - abruptly break the fist listener (see " r1.close() " line)
>>  - add another listener, verify that in fact we can't receive messages,
>>    as the server closed the connection.
>>  - In such case the server is allowed to behave in two different
>>    flavours:
>>     1) it may just forget about the session and answer with open frame
>>         (ie: start a new session). The sockjs-client will detect that
>> and complain.
>>     2) set a close reason to "Connection interrupted" on the session
>>        and give us a close frame with this reason.
>
>
> If the session has been destroyed then I don't see how you return
> "Connection Interrupted" since that would require some session state on the
> server to remain so you know the session has been "interrupted".

Correct. You can choose one of two behaviours:
- keep the state as usually, in such case mark the session
as closed with the reason "Connection interrupted"
- remove the session state, forget about it.

You can choose one of those options.

> Unless of course, aborting doesn't mean destroying the session?
>
> Another thing I don't understand is when a session is closed by the server
> due to it being closed by the application explictly or session timeout.

Okay, but keep in mind that these are two separate ways
of closing a session. Let's talk about the application on a
server side doing a close.

> This seems to be tested by test_close_frame:
>
>    # When server is closing session, it should unlink current
>    # request. That means, if a new request appears, it should receive
>    # an application close message rather than "Another connection
>    # still open" message.
>
> But again, if I've closed the session, how can I return such a message since
> I will require state to remain so I can return "go away"?

Yes, server must keep some state around for some time after the
session is closed.
This state must at least data required to emit a close frame.

Marek