B4J Question Websocket, session and websocket handler class instance.

[LucaMs]

Reading (and badly answering) this thread:
https://www.b4x.com/android/forum/threads/question-about-jserver-websocket-handle.95966/
I learned that if a websocket was closed, the related session would not automatically be destroyed.

So now I have many doubts.

In my project (b4j - jServer), when a client connects and the user is authenticated, I add "its related websocket handler class instance" to a global project map (in which the keys are the users' IDs).

If the client's websocket was closed and then the client tried to reconnect, I thought that a new instance (websocket handler class) was created on server, thus containing its new websocket object and I would proceed by "replacing" the instance stored in the global map with the new one (actually copying some properties from the new instance to the old one).

Since in that thread Erel states that a session of a closed websocket will be kept active and it (the session) would be reused in case of client reconnection, now I suppose that a new instance of the websocket handler class will not be created.

Is it so?

And if so, what exactly happens? What events would be raised? How should the server handle this thing?

 

[LucaMs]

Probably I don't need an answer (at least to solve "my problem", although it is still a good question, I think), because I can simply use Session.Invalidate or set Session.MaxInactiveInterval as Erel suggested. This way, I think, a new instance of the websocket handler class will be created when the client riconnects.

 

[OliverA]

Some ramblings on this subject:

Session <> WebSocket
When you at first connect to a B4J WebSocket handler, two things are created:

1. Jetty creates a new "session" for your browser. This "session" is managed by Jetty. If you look at your browser's cookies, you should now see a cookie named JSESSIONID. This cookie's value probably starts with "node". The expiration of that cookie is set to session, meaning that when you close the browser, the cookie "disappears". If you reopen the browser and reconnect to the site, a new Jetty session will be created. What happens to the old session? Looks like it will be kept around by Jetty since the default inactive timeout time for sessions is -1 (keep indefinitely). Please note, by default Jetty stores session information in memory and a shutdown of the Jetty server (be it a clean shutdown, a crash or a restart) will erase all session information (active and inactive).
   
2. Jetty creates a new handler, which in our case will be a WebSocket handler. This handler can set/delete/access any information that it wants to in the above mentioned Jetty session. Alll information created will be managed by the Jetty server and the browser never sees it (except for the JSESSIONID cookie) without you explicitly sending the information to the browser.

Now, as long as there is no break in communications, the same WebSocket object will take care of all WebSocket communication. If, for some reason, communication failure happens, then next access by the client application will create a new WebSocket object (but not necessarily a new Jetty session). By using Jetty's session management, one can figure out if a newly established WebSocket object is either a brand new connection or a re-establishment of a previously existing connection (see https://www.b4x.com/android/forum/threads/server-automatic-reconnecting-websocket.62054/). What happens to the old WebSocket? The JVM should clean it up, since it is not used anymore (unless you happen to keep it in some sort if list).

In regards to session management: in a lot of other web programming environments, part of a user log out procedure includes the invalidating of the active session behind the web connection.

So:

In my project (b4j - jServer), when a client connects and the user is authenticated, I add "its related websocket handler class instance" to a global project map (in which the keys are the users' IDs).

Ok

If the client's websocket was closed and then the client tried to reconnect, I thought that a new instance (websocket handler class) was created on server, thus containing its new websocket object and I would proceed by "replacing" the instance stored in the global map with the new one (actually copying some properties from the new instance to the old one).

It depends how it was closed. If the user closed the browser/browser crashed, the user will get a new WebSocket and a new session. If the WebSocket is closed, but not the browser, then a reconnection should create a new WebSocket, but you should still have the same session (unless it was invalidated).

Since in that thread Erel states that a session of a closed websocket will be kept active and it (the session) would be reused in case of client reconnection, now I suppose that a new instance of the websocket handler class will not be created.

The session will remain active as long as the browser is not closed. After a browser closes, that session is technically orphaned (on the Jetty side) and will not be used again. A server shut down/restart will clear all active and orphaned sessions. Any sessions after starting the server back up will be new sessions.
A new instances of a WebSocket will always be created if a WebSocket is closed or otherwise disconnected. A new WebSocket is not just triggered programmatically or closing the browser tab or the browser itself. A new WebSocket can also be triggered by timeout periods/inactivity and communication failure(s).

because I can simply use Session.Invalidate or set Session.MaxInactiveInterval as Erel suggested.

Yes. You can use Session.Invalidate before a controlled closing of a WebSocket (such as a log out) and the next connection will result in a new WebSocket and a new session. Session.MaxInactiveInterval can be used to clean up after cases where a user did not log out either by 1) period of inactivity 2) just closing out the browser or 3) a browser crash.

And if so, what exactly happens?

Hopefully I provided some insights (it's definitely not exact)

What events would be raised?

I don't think there are any (besides the events offered in the handler object)

How should the server handle this thing?

That may need to be specific to the implementation/purpose of the site in question

 

[LucaMs]

I still have to read well your post (I read it quickly) and thank you for your explanation.

Unfortunately I did not specify that the client is a B4A app, I do not access through browsers; so I don't know if there is a cookie (I guess yes) nor where it can be (although this is not very important for me).

You are writing about websocket, session and browser but my question is, mainly, about websocket handler class instances on server.


Thank you, @OliverA

 

[Erel]

Since in that thread Erel states that a session of a closed websocket will be kept active and it (the session) would be reused in case of client reconnection, now I suppose that a new instance of the websocket handler class will not be created.

Is it so?

And if so, what exactly happens? What events would be raised? How should the server handle this thing?

You are confusing different things. Each time that a client connects, a new WebSocket handler instance is created. This is not related to the http session that you can get with ws.Session (and you are probably not getting it as it is less useful with WebSockets).

 

[LucaMs]

You are confusing different things.

The thread of which I published the link here in the first post put me in doubt.
In fact, using websockets I'm not interested in the session.